使用Azure托管标识从VS Code连接Azure自动化时出错

为什么本地Connect-AzAccount -Identity会失败 #

Azure的系统托管标识依赖Azure内部的元数据服务端点（http://169.254.169.254/metadata）获取令牌，这个端点仅对Azure虚拟机、自动化账户等Azure托管资源可见，本地VS Code环境无法访问该端点，因此会抛出令牌获取失败的错误。

本地测试的替代方案 #

方案1：用个人Azure AD账户交互式登录 #

直接用自己的Azure AD账户完成本地测试，测试通过后再切换回托管标识代码发布到自动化账户：

# 本地测试专用，发布时替换为Connect-AzAccount -Identity
Connect-AzAccount -TenantId "你的Azure AD租户ID"

登录后会使用你账户对应的权限执行Runbook逻辑，完全满足测试需求。

方案2：用服务主体模拟托管标识 #

如果需要更贴近自动化账户托管标识的权限范围（避免个人权限过大），可以创建一个服务主体，赋予其和自动化账户托管标识相同的IAM权限，然后本地用服务主体登录：

$clientId = "服务主体ID"
$tenantId = "租户ID"
$clientSecret = ConvertTo-SecureString "服务主体密钥" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($clientId, $clientSecret)

Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $tenantId

迁移到Microsoft Graph的优化方案 #

既然要弃用AzureAD模块，推荐直接基于Microsoft Graph PowerShell模块重构脚本，更适配Azure未来生态：

• 自动化账户内用托管标识连接Graph：

# 自动化账户环境自动使用系统托管标识
Connect-MgGraph -Identity
# 示例：执行Graph操作
Get-MgUser -Top 10

• 本地测试Graph连接：
  用交互式登录获取所需权限：

# 本地测试，指定需要的权限范围
Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All"

也可以用服务主体登录，贴合自动化环境的权限逻辑：

Connect-MgGraph -ClientId $clientId -TenantId $tenantId -ClientSecretCredential $credential

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