Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.

Reply
swise001
Continued Contributor
Continued Contributor

"Test as Role" function is not consistently overriding UPN / Username when used.

In short - when I use the "test as role" function in Power BI service - sometimes it works and sometimes it doesn't work.

 

To test what I was seeing - I created a file that simply displayed the measure USERPRINCIPALNAME() on the report canvas.  Using the "test as role" feature - I was able to enter various email addresses and effectively toggle which UPN appears in this measure (so long as they were included in the security role).  This is the expected behavior of the "test as role" feature.  

 

Lately, however, this has been inconsistent.  I've now tried to use the same functionality and found that it no longer impacts these measures, instead defaulting to my UPN,  rather than the one I select in the "test role as" feature.  I've seen it fluctuate from working to not working in a matter of hours - and this inconsistency is worrisome. 

 

Is anyone else experiencing this?

1 ACCEPTED SOLUTION
swise001
Continued Contributor
Continued Contributor

I've been able to reproduce this issue: 


Here's what I did.  I have a workspace with 3 users: 

 

User 1: Admin (me)

User 2: Contributor

User 3: Viewer

 

From the dataset security menu - I proceed to "test as role".  When I test as User1, USERPRINCIPALNAME() returns my credentials (which is expected).   When I proceed to test for User2 - USERPRINCIPALNAME() returns MY credentials again!   When I test for User3 - USERPRINCIPALNAME() returns the credentials for User3. 

 

If I remove User2 from the workspace entirely - and then try to test for him again - USERPRINCIPALNAME() continues to incorrectly return my credentials for at least 30 minutes (while the system is probably syncing the changes).   This persists even if I try in other browsers or with a private browser session.  

 

I'm not exactly sure why this happens, but it does.  This is likely related to the interplay of Userprincipalname with workspace roles (Admin,Member,Contributor) where RLS doesn't apply.   Perhaps the measure inherits the Admin credentials for all priviledged users in the workspace??  The fact that it persists well after the priviledged user is removed from the workspace - can also make it quite confusing.

RLS.png

 

Marking as solved because: 

1.  For all users not in Member or Contributor roles - USERPRINCIPALNAME() returns the correct result. 

2.  Removing a priviledged user from Workspace eventually updates the measure result (after about 30-40 minutes).

3.  It's likely that the issues described above are not issues, but rather artifacts of how PowerBI removes RLS for users in Member and Contributor roles.  

View solution in original post

2 REPLIES 2
GilbertQ
Super User
Super User

Hi there

It has been working for me in the past

Has anything else changed in the configuration of your roles?




Did I answer your question? Mark my post as a solution!

Proud to be a Super User!







Power BI Blog

swise001
Continued Contributor
Continued Contributor

I've been able to reproduce this issue: 


Here's what I did.  I have a workspace with 3 users: 

 

User 1: Admin (me)

User 2: Contributor

User 3: Viewer

 

From the dataset security menu - I proceed to "test as role".  When I test as User1, USERPRINCIPALNAME() returns my credentials (which is expected).   When I proceed to test for User2 - USERPRINCIPALNAME() returns MY credentials again!   When I test for User3 - USERPRINCIPALNAME() returns the credentials for User3. 

 

If I remove User2 from the workspace entirely - and then try to test for him again - USERPRINCIPALNAME() continues to incorrectly return my credentials for at least 30 minutes (while the system is probably syncing the changes).   This persists even if I try in other browsers or with a private browser session.  

 

I'm not exactly sure why this happens, but it does.  This is likely related to the interplay of Userprincipalname with workspace roles (Admin,Member,Contributor) where RLS doesn't apply.   Perhaps the measure inherits the Admin credentials for all priviledged users in the workspace??  The fact that it persists well after the priviledged user is removed from the workspace - can also make it quite confusing.

RLS.png

 

Marking as solved because: 

1.  For all users not in Member or Contributor roles - USERPRINCIPALNAME() returns the correct result. 

2.  Removing a priviledged user from Workspace eventually updates the measure result (after about 30-40 minutes).

3.  It's likely that the issues described above are not issues, but rather artifacts of how PowerBI removes RLS for users in Member and Contributor roles.  

Helpful resources

Announcements
Microsoft Fabric Learn Together

Microsoft Fabric Learn Together

Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City

PBI_APRIL_CAROUSEL1

Power BI Monthly Update - April 2024

Check out the April 2024 Power BI update to learn about new features.

April Fabric Community Update

Fabric Community Update - April 2024

Find out what's new and trending in the Fabric Community.

Top Solution Authors
Top Kudoed Authors