为何RLS在外部表格模型可用 但Power BI内置模型中失效报错

你遇到的问题本质是SQL Server Analysis Services(SSAS) Tabular企业级模型和Power BI内置数据集的行级别安全(RLS)执行逻辑、上下文规则存在本质差异，完全照搬配置必然会出现不兼容，具体差异和触发报错/失效的原因如下：

• 执行层位置不同
  你在Visual Studio中构建的Tabular Cube运行在独立的SSAS服务端，RLS逻辑在服务端统一执行，服务端会自动处理筛选路径冲突、权限上下文传递问题，完成权限校验后才会把筛选后的数据返回给连接的报表，不会受报表端配置影响，因此你做的两份报表只要连接同一个Cube，权限逻辑都能正常触发。
• 关系筛选规则差异
  SSAS服务端的RLS默认会自动绕开双向关系导致的筛选循环问题，优先沿着权限控制表（你用的access table）到业务表的路径完成筛选；但Power BI内置数据集的RLS严格遵循模型中配置的关系筛选方向，如果你在Power BI模型中给访问表和业务表开了双向筛选，且业务表和其他维度表也存在双向关系，RLS运行时会检测到筛选路径闭环，直接抛出你遇到的运行错误。
• 角色权限边界差异
  SSAS Tabular原生支持多角色权限叠加、服务端自动识别访问者身份匹配对应角色权限，你给普通用户、管理层配置的差异化权限可以自动生效；但Power BI内置数据集的RLS需要手动明确每个角色的权限范围：如果没有给管理层角色单独配置全量数据读取权限、反而把[访问标记] = 1的规则应用到了所有角色，管理层账号也会被强制套上个人数据筛选；如果规则中用到USERPRINCIPALNAME()做身份匹配，SSAS默认返回域\账号格式的身份标识，Power BI服务中返回的是用户UPN邮箱格式，格式不匹配时会直接匹配不到标记为1的权限记录，导致筛选失效。
• 依赖表权限配置差异
  SSAS中RLS规则引用的访问控制表默认对所有角色开放读取权限，不需要额外配置；但Power BI内置数据集中，如果RLS引用的访问表没有给对应角色开放基础读取权限，或者被设置为对该角色隐藏，规则运行时找不到引用对象，就会直接触发配置报错。

修正配置的可落地步骤 #

1. 调整模型关系：将访问表和业务主表的关系设置为单方向筛选（访问表→业务表），关闭涉及RLS筛选路径的所有双向关系，避免筛选循环报错。
2. 拆分角色权限：单独创建两个角色，普通用户角色应用你原有的[访问标记] = 1筛选规则，管理层角色不添加任何RLS筛选规则，开放所有业务表的全量读取权限；两个角色都需要给访问表开放最小读取权限，不要针对角色隐藏访问表。
3. 校验身份匹配逻辑：如果用账号匹配访问表的权限记录，确认USERPRINCIPALNAME()返回值和访问表中存储的账号格式完全一致，避免格式不匹配导致的筛选失效。
4. 本地验证时使用Power BI Desktop顶部菜单栏的「以角色身份查看」功能，分别选择两个角色验证筛选结果——建模视图默认使用管理员上下文，不会触发RLS，直接查看数据无法验证规则是否生效。

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