SQL Always Encrypted对接Key Vault时PowerShell交互式登录报AADSTS500200

该报错与账号Key Vault访问权限、订阅所有者身份无关，核心是Add-SqlAzureAuthenticationContext默认交互式认证逻辑存在租户识别缺陷，叠加更换新电脑丢失本地旧认证缓存的场景触发：

• 无附加参数执行Add-SqlAzureAuthenticationContext -Interactive时，cmdlet默认将认证请求路由到AAD通用认证端点，不会自动携带当前操作的Azure租户ID。使用个人Microsoft账号（MSA）登录时，AAD无法自动关联账号对应的目标租户，会默认判定登录行为是访问未对该账号发出邀请的外部组织资源，直接抛出AADSTS500200错误。
• 旧设备可正常运行的原因，通常是历史执行命令时曾显式传入租户ID，参数被缓存在本地PowerShell会话配置中，无需每次手动传入；更换新电脑后本地缓存清空，就会触发默认逻辑的问题。
• 临时切换client secret认证可正常生效，是因为服务主体认证流程会强制携带指定租户标识，不存在个人账号场景下的租户路由错误。
• 低版本SqlServer模块的交互式认证逻辑本身存在个人MSA账号兼容缺陷，也会触发同类报错。

按优先级依次操作即可恢复交互式登录能力：

方案1：显式指定租户ID执行认证（90%以上场景可直接解决） #

1. 先通过当前可用的client secret认证上下文执行Get-AzTenant，获取目标Azure订阅对应的租户ID（格式为GUID）。
2. 升级SqlServer模块到最新版本，避免旧版本兼容问题，执行以下命令后重启PowerShell会话：

Update-Module -Name SqlServer -Force

3. 执行交互式认证时显式传入租户ID参数：

# 将引号内内容替换为实际获取到的租户ID
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Add-SqlAzureAuthenticationContext -Interactive -TenantId $tenantId

执行后按正常流程完成账号登录即可，认证逻辑和你之前旧设备的使用体验完全一致，无需修改现有加解密脚本的其他业务逻辑。

方案2：调整账号租户成员类型（方案1无效时使用） #

如果传入正确租户ID后仍报相同错误，需检查个人账号在目标AAD租户中的用户类型：

• 登录Azure Portal进入Azure Active Directory管理页
• 打开「用户」列表，搜索你使用的个人MSA账号
• 进入账号详情页，检查「用户类型」字段，如果显示为「来宾」，编辑修改为「成员」后保存，重新执行交互式认证即可。

完成认证后，执行原有数据加解密脚本的测试用例，确认可正常访问Key Vault、SQL相关资源即代表修复完成。

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