Azure AD用户Global Reader角色验证及SignInActivity查询权限问题

1. 无需Global Reader角色访问SignInActivity数据的权限说明 #

• 分两种调用场景对应不同规则：
  • 若使用应用权限（无用户登录上下文的服务类调用）：只需给应用授予AuditLog.Read.All或Directory.Read.All的应用权限，完成管理员同意后即可正常拉取SignInActivity数据，不需要给任何身份分配Global Reader角色，不会触发角色校验报错。
  • 若使用委托权限（用户登录后携带用户身份上下文调用）：目前没有任何独立的安全作用域可以绕过接口的目录角色校验逻辑。即使你已经配置了AuditLog.Read.All委托权限，登录用户仍需属于以下内置目录角色之一才能正常访问数据，除Global Reader外可选的更低权限角色包括：安全读取者、报告读取者、安全管理员、全局管理员。只要用户不在上述角色范围内，就会抛出User is not in the allowed roles错误。

2. 通过Microsoft Graph校验用户是否分配Global Reader角色的实现方式 #

• Global Reader是Azure AD内置固定角色，对应的角色模板ID为f2ef992c-3afb-46b9-b7cf-a126ee74c451，可以通过以下两种接口逻辑完成校验，调用接口需要至少Directory.Read.All的委托或应用权限：
  • 单用户校验：调用GET /v1.0/users/{目标用户Object ID}/transitiveMemberOf/microsoft.graph.directoryRole接口，遍历返回结果中的roleTemplateId字段，若存在值为上述模板ID的条目，即代表该用户（包含直接分配、通过组嵌套继承的场景）持有Global Reader角色。注意不要使用非transitive的memberOf接口，该接口无法识别通过嵌套组继承的角色，会出现漏判。
  • 批量校验：先调用GET /v1.0/directoryRoles/roleTemplateId='f2ef992c-3afb-46b9-b7cf-a126ee74c451'/members接口，拉取所有持有Global Reader角色的主体列表，再和待校验用户做匹配即可。

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