使用服务主体调用AD Graph用户重置密码接口返回403错误求助

咱们先拆解下你遇到的核心矛盾：服务主体明明拿到了AD Graph和Microsoft Graph的全量应用权限，也完成了管理员同意，但调用单个用户详情接口返回403，批量读取用户列表却完全正常，连Microsoft Graph端也有类似问题。结合你的描述，我整理了几个可能的遗漏点和对应解决方向：

1. 确认令牌的受众与权限匹配 #

你获取AD Graph令牌时指定的资源是https://graph.windows.net，这点是对的，但要检查令牌的aud（受众）声明是否确实是这个值——要是不小心混淆了Microsoft Graph的资源地址，会直接导致权限不匹配。另外你提到实际授予8个权限但令牌里只显示7个，建议核对缺失的那个权限是否是单个用户读取必需的（不过Directory.Read.All理论上已经覆盖了用户读取能力）。

2. 服务主体可能需要补充目录角色授权 #

虽然Directory.Read.All这类应用权限理论上允许服务主体读取所有用户数据，但在AD Graph的部分场景下，服务主体还得被分配目录角色才能访问单个用户详情。比如可以尝试给服务主体分配「全局读取者」角色，操作路径是：Azure门户 → Azure AD → 角色和管理员 → 找到对应角色 → 添加成员 → 选择你的服务主体。

3. 目标用户的特殊权限限制排查 #

如果目标用户所在的OU（组织单元）开启了权限继承阻断，或者用户个人属性设置了特殊访问控制，可能会导致服务主体无法读取该用户详情。你可以检查目标用户所在OU的权限设置，确认是否允许服务主体的应用身份读取用户数据。

4. Microsoft Graph场景的适配调整 #

针对Microsoft Graph的情况，注意两个关键点：

• 获取令牌时，资源地址要改为https://graph.microsoft.com，不能再用AD Graph的地址；
• 服务主体调用GET /users/{id}需要的是Directory.Read.All或User.Read.All应用权限，而你在Graph Explorer中看到的Directory.AccessAsUser.All是委托权限（用户上下文），和服务主体的应用权限逻辑完全不同，两者不能直接对比。

权限与API操作映射的参考 #

你可以参考微软官方文档中关于Azure AD Graph和Microsoft Graph的应用权限与API操作映射说明，里面会明确每个权限对应的可执行操作，以及服务主体所需的配置要求。

内容的提问来源于stack exchange，提问作者Jim O'Neil