Azure账户Add Role Assignment禁用时能否为应用添加角色分配？

结论 #

可以。 门户中Add Role Assignment按钮灰置仅代表前端页面判定当前场景下不展示可点击入口，只要你的账户确实持有对应作用域的角色分配写入权限（即Microsoft.Authorization/roleAssignments/write操作权限，和你截图中展示的权限匹配），完全可以绕过门户前端限制完成角色分配。

你当前账户持有的权限参考：

你遇到的按钮禁用状态参考：

可用操作方式 #

• 使用Azure CLI完成分配
  打开本地终端或者Azure门户顶部的Cloud Shell，登录对应账户后执行以下命令：

  # 替换<目标应用客户端ID>为你要分配角色的应用程序Application (client) ID
  $servicePrincipalId = az ad sp show --id <目标应用客户端ID> --query id -o tsv
  # 替换<角色名称>为要分配的角色名（比如Contributor、Reader），替换<作用域ID>为分配生效的订阅/资源组/资源ID
  az role assignment create --assignee $servicePrincipalId --role "<角色名称>" --scope "<作用域ID>"
  

  命令执行成功即代表角色分配完成，无需依赖门户按钮状态。

• 使用Azure PowerShell完成分配
  若你习惯使用PowerShell，登录Az模块后执行以下命令即可：

  # 替换<目标应用客户端ID>为实际值
  $sp = Get-AzADServicePrincipal -ApplicationId <目标应用客户端ID>
  # 替换<角色名称>、<作用域ID>为实际值
  New-AzRoleAssignment -ObjectId $sp.Id -RoleDefinitionName "<角色名称>" -Scope "<作用域ID>"
  

• 直接调用Azure Resource Manager REST API分配
  你也可以直接在Cloud Shell中获取访问令牌后，调用REST接口提交分配请求，完全绕过门户的前端校验逻辑：

  PUT https://management.azure.com/<作用域ID>/providers/Microsoft.Authorization/roleAssignments/<自定义GUID作为分配唯一ID>?api-version=2022-04-01
  Content-Type: application/json
  
  {
    "properties": {
      "roleDefinitionId": "<作用域下对应角色的完整资源ID>",
      "principalId": "<目标应用对应的服务主体对象ID>"
    }
  }
  

按钮禁用的常见原因 #

门户按钮灰置通常不是权限不足导致，常见触发场景包括：当前访问的目录blade存在前端兼容性bug、全局管理员未激活租户根作用域的提升权限、租户条件访问策略限制了门户内的角色分配操作、当前选中的作用域为系统预留不支持门户直接分配。只要你确认自身持有对应写入权限，上述命令行/API方式均可正常完成操作。

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