Bug: Dax queries execution permission issues on workspaces where AD groups are used for access

[wlknsnBI]

When we programtically run dax queries on datasets, where the executing user is not defined directly in the access area of the workspace and/or the dataset itself, the dax query will fail due to permissions eventhough a AD group was added with build permissions on the dataset and/or workspace (and the user is part of this AD group).

There are two workarounds:

* The user visits first the workspace on powerbi.com service. That somehow authenticates the user sucessfully and so after which the dax query will run. (Don't even have to visit the dataset, just going to the workspace seems to clear the issue).

* The user account gets added directly to the workspace. Then also the dax query will run without an issue.

To replicate: know that this only fails once. So any user who visits the workspace or who gets authenticated once correctly, it no longer occurs. Of course, in terms of scalability, this is a huge issue. You cannot ask to have all users visit the workspace first or to manually add all the user seperately. 

For now, we will start executing the queries using a service principal, but hope someday this bug gets resolved so they can be ran as inidividual user queries as it should in our case.

[v-xiaoyan-msft]

Hi @wlknsnBI ,

"any user who visits the workspace or who gets authenticated once correctly," It seems by desgin.

If you would like to suggest  feature improvements, you may  vote the idea and comment here  to improve this feature. It is a place for customers provide feedback about Microsoft Office products . What’s more, if a feedback is high voted there by other customers, it will be promising that Microsoft Product Team will take it into consideration when designing the next version in the future.

Best Regards,
Community Support Team _ Caitlyn

[wlknsnBI]

So you are suggesting that prior to being able to use dax query execeution via rest api, that the user who want to execute first needs to open the workspace before he/she can run the query? That makes no sense what so over.

The authentication is simply failing when it shoudln't (via api).

How can you mark that as delivered?? 

[wlknsnBI]

@v-xiaoyan-msft 

You can replicate this bug by doing the following: 

1) create a Workspace1 with a report

2) assign an AD group with build/read permissions to this Workspace1

3) add UserX to the AD group

4) login to powerautomate with UserX

5) run dax query against dataset in Workspace1

... see how it fails with an error about permissions eventhough you are part of the AD group of Workspace1.

HOWEVER,
1) if UserX now manually visits the Workspace1 in the powerbi.com service, and then tries the powerautomate flow again, it will work. So it's the authentication via REST API that isn't working properly.
2) if you remove AD group and add UserX directly to the workspace, this also works from the first go. But of course:

a) this is not scalable

b) this is very different from any other behavior with AD groups in powerbi.com service

c) this isn't documented as being a limitation

d) given that it works after visting the workspace manually, means that post authentication, it does allow the user to do the necessary.

So after intensive tests with multiple user accounts on of your biggest enterprise customers, the bug is that via rest api call (dax query), the authentication can't seem to validate the user in an AD group assigned to a workspace. 

PS: the authentication works in any other typical scenario like normal workspace/report access, but it doesn't work using POWERBI REST API.