使用Veeam在Azure中创建计算账户失败请求排查

看起来你已经做了不少基础操作——身为全局管理员和订阅所有者，还跟着官方文档走了流程、尝试了自定义角色，结果还是碰到了权限不足的报错，确实挺头疼的。结合你给出的日志（Authorization_RequestDenied错误），我从几个方向帮你排查：

1. 优先排查Azure AD层面的权限限制 #

订阅所有者权限主要管资源层面的操作，但Veeam用Device Code Flow创建计算账户时，需要在Azure AD中自动注册服务主体，这一步的权限是AD层面的，和订阅权限是分开的：

• 检查Azure AD的「用户设置」：进入Azure AD控制台 → 企业应用程序 → 用户设置，确认「用户可以注册应用程序」选项是否设为「是」。如果这个选项是关闭的，哪怕是全局管理员也没法自动创建服务主体，自然会触发权限不足的报错。
• 确认全局管理员的权限是否被限制：有些租户会给全局管理员设置权限边界，或者启用了「特权身份管理(PIM)」，如果你的全局管理员角色是需要激活的，记得先激活再操作。

2. 检查自定义角色的权限覆盖范围 #

如果手动添加了自定义角色，确保它包含Veeam创建计算账户必需的权限，至少要覆盖：

• Microsoft.Compute/*（计算资源全权限）
• Microsoft.Resources/subscriptions/resourceGroups/*（资源组创建/管理权限）
• Microsoft.Authorization/roleAssignments/write（分配角色权限）
• Microsoft.AAD/servicePrincipals/write（创建服务主体权限）

可以在Azure的角色分配界面，对比Veeam官方推荐的权限清单，看看有没有遗漏的项。

3. 排查条件访问策略的影响 #

有些租户的条件访问策略会限制Device Code Flow这种认证方式：

• 进入Azure AD控制台 → 条件访问，检查有没有针对「用户操作」或「应用程序」的策略，比如要求MFA、限制登录位置，或者直接阻止了设备码流认证。如果有相关策略，可以临时禁用测试，或者把Veeam相关的操作加入例外。

4. 尝试手动创建服务主体再关联Veeam #

如果自动创建服务主体的路径走不通，可以换个思路：

1. 手动在Azure AD中创建一个服务主体，给它分配订阅所有者（或足够的计算资源权限）；
2. 在Veeam创建计算账户时，选择「使用现有服务主体」的选项，填入手动创建的服务主体的ID和密钥；
3. 尝试完成账户创建，看是否能绕过自动注册的权限问题。

备注：内容来源于stack exchange，提问作者Milton Steven Jimenez