Users with Multiple Roles Error

[bjkoning-bince]

We are experiencing the same issue as reported here: https://community.powerbi.com/t5/Desktop/Users-with-multiple-security-roles-suddenly-can-t-see-data/...

The Power BI service is throwing an "SecurityFilteringBehavior=Both" error on all visuals for RLS users linked to multiple roles. There are no bidirectional security filters present, after checking in Tabular Editor and the relation editor in Powr BI. It happens on all datasets that have the same users in different roles in RLS. Those assigned a single roles experience no issues.

For us this behavior is new and has worked until a week or so ago. I have not been able to resolve it other than having non-overlapping roles as a workaround.

[jobosol]

I got a new response on my ticket, and this issue is by design because of a potential data leak. 

Full response: 

"We would like to let you know that we got further update from our internal product team saying that the issue which you are currently facing is due to a design change from our end!

Product team has enabled a feature - switch DAXStrictMultiRolesQueryPlanValidation, adding validation for RLS application to prevent potential data leak. This is an RLS Security enhancement from Power BI. This will be updated in the public documentation soon.

Below are the complete details:
 
Nature of impact: Power BI customers might experience issues while loading visuals and DAX queries will be blocked if below all conditions met:
1. Model has multiple RLS roles with DAX filters.
2. The query is executed from user who belongs to multiple RLS roles with DAX filter.
3. Some table with weak relationship is involved in the query.

Before the change: RLS filters won't work (customer might not notice this) if multiple RLS roles with DAX filter + weak relationships are involved, as a result, there will be potential data leak. 

After the change\FS enabled: The problematic scenario will be blocked when the query is executed.
 
Currently this is in Premium Capacity and from Desktop SU12.

Workaround: 
• Customer can move to shared capacity if needed. But this validation will be also enabled in PBI Shared later. And ultimately this validation will be enabled by default, and not controllable by flighting anymore at some point (maybe months later, TBD)

So, for the temporary mitigation, you can move to the Shared workspace since it is enabled in Premium.

Action needed from customer if they are facing the issue:  

Customer needs to fix their problematic model to remove the security risk. So, to improve your model and avoid this error, please follow the below steps. It is introduced only to avoid potential data leak and improve the RLS model.

Do not put any user into multiple roles:

• For a user, user A belongs to RLS roles A with DAX filter F_a, B with DAX filter F_b
• Create another RLS role AB, combine the DAX filters F_a and F_b => F_a UNION F_b
• Remove user A from A and B, and add user A into AB

"

[Anonymous]

This is surely not helping, we have cases where single user should be part of more than one roles, how many such combinations are we going to maintain now per user???
Also very surprised that such a major change was not announced!?

[Randel]

We experienced similar issue caused by many-to-many relationship.

The issue is fixed using the workaround to replace existing relationship:

{Source table}<Many-to-many | one direction>{Target Table}

with new relashiship:

{Source table}<Many-to-one | both direction>{intermediate table} <One-to-many | One direction>{Target Table}. 

Detailed steps:

1. Create a intermediate table which has only one column. Column data is distinct values of many-to-many relationship column of source table. 

2. Delete many-to-many relationship from source table to target table

3. Create many-to-one relationship from source table to intermediate table. Set relation filter to be both direction. 

4. Create one-to-many relationship from intermediate table to target table. Set relation filter to be one direction. 

[Gururaj]

Still the same issue, it has affected all of our users. Please let us know the estimated ETA for the resolution. 

[hashtag_pete]

Hello all, 

same here: we receive an error for users with multiple role assignments after December update. In the dataset we have a n:m one-directional relationship. 

Thanks for finding a solution

hashtag_pete

[schuffa]

Hi all, you might ask the MS suport team to set the DAXStrictMultiRolesQueryPlanValidation setting in your capactiy to false. This will disable the new "feature".
https://docs.microsoft.com/en-us/power-bi/admin/service-admin-rls#issue-multiple-roles-and-limited-r...

To me this was also very strange to install that w/o any announcement upfront. As we're using here dynamic RLS exactly building on (prior) possibility to use user groups having all report users in all RLS roles and only resolve those during the runtime versus a user access table resolving the dimensional access, this also hit us fully and did not allow from one day to another end users to access their information. 

Really looking forward to MS to ship something related to this note, which can be found in the MS support article following the link above:

"Note

We're aware that in many situations Power BI is too restrictive and the information can safely be shared between the sources involved. While we're working on releasing a solution for this situation, consider adopting one of the workarounds above."

-> Indeed this new feature is too strict now in my scenario here having this new feature on.

[KheldarSilk]

Hi all,

I have a case where this new control feature is really messing things up.

I have a PowerApps connected to an Azure SQL DB for internal expense requests, and just built a Power BI reporting on top of it.

There are different types of users :

1. Requesters who must only see their expense requests, filtered on the requester table

2. Cost center owners who must see their own expense requests outside the cost center as well as the requests from others within their cost center (=> two roles at a time)

3. Deparment and subdeparment managers who must see their deparment's requests as well as theirs

Do you have an idea of what the solution could be ?

It would be far more easier if Microsoft just addressed the issue, but still, I'm open to ideas.