使用VSTS PowerShell任务部署ADLA USQL CI/CD时遇权限拒绝错误

听起来你已经完成了基础的服务主体配置，但还是卡在了权限验证这一步，我来帮你梳理几个容易被忽略的排查方向：

• 确认RBAC权限的精准性与范围
  别只依赖通用的Contributor角色，ADLA有专属的Data Lake Analytics Contributor角色，这个角色包含了部署U-SQL作业所需的完整权限。另外要确认权限是直接分配给服务主体（而非通过Azure AD组），并且作用范围是目标ADLA账户本身（虽然上层资源组/订阅的权限也能继承，但直接分配到ADLA账户更稳妥）。

• 检查服务端点的身份验证细节
  如果服务主体用证书认证，务必确认VSTS服务端点里上传的证书包含完整私钥且未过期；如果是密码认证，检查密码是否过期，同时核对端点里的应用ID、租户ID和Azure Portal中创建的服务主体完全一致——字符输入错误是这类问题的常见诱因。

• 验证PowerShell任务的身份上下文
  确保你的PowerShell脚本里正确使用服务主体身份登录Azure，推荐用最新的Az模块命令：

  Connect-AzAccount -ServicePrincipal -ApplicationId $appId -TenantId $tenantId -CertificateThumbprint $thumbprint
  

  注意不要混用AzureRM和Az模块，旧模块的身份验证逻辑可能和ADLA的权限体系不兼容。

• 排查ADLA防火墙限制
  如果你的ADLA账户开启了防火墙，需要把VSTS代理的IP地址加入ADLA的允许列表，或者勾选ADLA防火墙设置里的"Allow Azure services and resources to access this Data Lake Analytics account"选项。有时候权限配置没问题，但防火墙直接拦截了请求，也会返回权限拒绝的错误，很容易混淆。

• 检查U-SQL脚本的依赖资源权限
  如果你的U-SQL脚本需要读写其他Azure存储（比如ADLS Gen2或Blob存储），服务主体还需要对应存储资源的权限，比如Storage Blob Data Contributor。ADLA执行脚本时会用当前身份（即服务主体）访问这些依赖资源，缺了这个权限也会抛出类似的拒绝错误。

• 等待权限生效或刷新会话
  Azure RBAC权限有时候会有几分钟的生效延迟，尤其是刚分配的权限。可以等10-15分钟再试，或者在PowerShell脚本里先登出再重新登录服务主体，刷新身份会话：

  Disconnect-AzAccount -Force
  Connect-AzAccount -ServicePrincipal ... # 重新执行登录命令
  

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