关于Power BI行级安全角色的技术问询：能否基于UPN过滤？

核心结论 #

可以使用userprincipalname()，能否基于UPN过滤的关键在于加密值与真实UPN的映射关系，而非函数本身。

具体分析 #

1. userprincipalname()的本质
   该函数的设计目标就是返回用户的用户主体名称（UPN，通常为企业邮箱格式）。即便在内部加密工作区返回加密值，这个加密结果也是与用户真实UPN一一对应的唯一标识，身份指向性明确。

2. 基于UPN过滤的可行性

   • 如果数据模型中存储的是加密后的UPN值，直接用userprincipalname()返回的加密结果做匹配过滤完全可行，两者能精准对应。
   • 如果模型中存储的是明文UPN，则需要确认内部工作区的加密是否支持可逆映射（比如通过Power BI行级别安全（RLS）的身份映射配置、后端身份系统的关联机制）。若无映射机制，加密值与明文UPN无法直接匹配，但这是工作区加密策略的限制，并非userprincipalname()的问题。

3. 与username()的对比优势
   虽然两者在内部加密工作区都返回加密值，但userprincipalname()的语义更贴合UPN标识，且在常规环境（Desktop/普通Power BI Service工作区）返回格式统一（邮箱格式）。后续若工作区加密策略调整，无需修改代码，兼容性更强；而username()在Desktop返回Domain\用户名格式，环境差异大，维护成本更高。

实践建议 #

优先使用userprincipalname()实现基于UPN的身份过滤逻辑，即便当前工作区返回加密值，只要确保数据模型中的身份标识（无论明文还是加密）能与该函数返回值对应即可。

内容的提问来源于stack exchange，提问作者Sophia