Forum Discussion
RLS - Users See No Data Due to Email Alias vs. USERPRINCIPALNAME Mismatch (Workspace App)
Hi all,
We have two Import mode semantic models with RLS defined via a security mapping table, both using Workspace App audience security.
Working: Model 1 : users authenticate with their primary UPN and RLS filters correctly.
Broken: Model 2 : affected users have an email alias (e.g., [email protected]) that differs from their UPN (e.g., [email protected]). When we add them to the app using their primary email, the system resolves and displays the alias instead. The result is that USERPRINCIPALNAME() appears to return the alias at runtime, which doesn't match the value in the mapping table , so users see no data.
Questions:
What does USERPRINCIPALNAME() actually return for aliased users in Fabric?
Should the mapping table store the alias, UPN, or both?
Is there a recommended pattern for handling this alias/UPN mismatch in RLS?
Thank you all for the thoughtful responses After further investigation, I want to share an update that may help others facing similar symptoms.
In our implementation, we do not rely on a security mapping table for RLS evaluation. Instead, our models resolve identity directly from the user's Active Directory, which means the email alias vs. UPN mismatch was not the root cause in our case.
The actual issue turned out to be a misconfigured security group that had been inadvertently added to the Workspace App audience with elevated privileges. This group's permission scope was conflicting with and overriding the expected RLS enforcement for a subset of users effectively causing them to fall outside the intended access boundary and return no data.
Once the security group was identified and removed, RLS resolved correctly for all affected users.
Thank you again.
5 Replies
Thank you all for the thoughtful responses After further investigation, I want to share an update that may help others facing similar symptoms.
In our implementation, we do not rely on a security mapping table for RLS evaluation. Instead, our models resolve identity directly from the user's Active Directory, which means the email alias vs. UPN mismatch was not the root cause in our case.
The actual issue turned out to be a misconfigured security group that had been inadvertently added to the Workspace App audience with elevated privileges. This group's permission scope was conflicting with and overriding the expected RLS enforcement for a subset of users effectively causing them to fall outside the intended access boundary and return no data.
Once the security group was identified and removed, RLS resolved correctly for all affected users.
Thank you again.
Hi lamisghoualmi ,
We are pleased to know that the issue has been resolved. Thank you for sharing the resolution; it will be very helpful for other members who may face similar challenges.
Please continue using Microsoft fabric community forum.
Best Regards,
Abdul Rafi
Hi lamisghoualmi ,
1. What does USERPRINCIPALNAME() actually return for aliased users in Fabric?
Gives whatever email they clicked to log into your app (like [email protected]), not their main UPN ([email protected]).2. Should the mapping table store the alias, UPN, or both?
Both emails, same person.
User123 | [email protected] | Dept A
User123 | [email protected] | Dept A3.Is there a recommended pattern for handling this alias/UPN mismatch in RLS?
The Users table needs:
- UserID (like employee id)
- Email (both UPN + alias row entries)
- DeptAccess (Dept A, Dept B)RLS DAX will be: [Email] = USERPRINCIPALNAME()
Hope this resolves your issue.
Thanks,
Pallavi
I have run into similar issues with the UPN data in the past. What I would recommend doing is going into Entra ID and see what the UPN pattern is and then use that pattern to be applied for the users when using RLS because as mentioned before it will always go back and use the user principal name and not the display name or email address which sometimes can be different.
The safest approach is to store the UPN since that is what USERPRINCIPALNAME() is designed to return. You can verify each affected user's actual UPN by asking them to run a simple report with a card showing USERPRINCIPALNAME(), whatever that card displays is what the mapping table must contain for that user.
