如何为连接Azure SQL数据库的PowerBI仪表板配置Azure AD服务主体身份验证的数据源凭据

我来帮你搞定这个头疼的问题——你现在用OAuth2的accessToken会1小时过期，导致必须频繁重新部署仪表板，而Basic类型又因为Azure SQL只开了AAD认证报错，核心问题是没用到Power BI专门针对Azure AD服务主体的凭据类型。

正确的credentialDetails配置 #

你需要把credentialType设置为AADServicePrincipal，而不是之前的OAuth2或Basic。这种类型下，Power BI会自动处理服务主体的令牌刷新，不用你手动维护短期的accessToken，彻底解决过期问题。

完整的配置示例如下：

{
  "credentialDetails": {
    "credentialType": "AADServicePrincipal",
    "credentials": "{\"credentialData\":[{\"name\":\"clientId\",\"value\":\"你的服务主体客户端ID\"},{\"name\":\"clientSecret\",\"value\":\"你的服务主体密钥\"}]}",
    "encryptedConnection": "Encrypted",
    "encryptionAlgorithm": "None",
    "privacyLevel": "None"
  }
}

各字段说明 #

• credentialType: 必须指定为"AADServicePrincipal"，这是Power BI为Azure AD服务主体认证提供的专属类型，完美适配Azure SQL的AAD-only认证要求。
• credentials: 是转义后的JSON字符串，包含两个关键数据：
  • clientId: 你的Azure AD服务主体的客户端ID
  • clientSecret: 服务主体的密钥（注意在CI/CD中一定要用安全变量存储，绝对不能硬编码）
• encryptedConnection: 保持"Encrypted"符合安全合规要求
• encryptionAlgorithm: 设置为"None"即可，因为AAD认证本身已经提供了足够的安全保障
• privacyLevel: 根据你的公司合规政策调整，"None"是通用的安全选择

为什么之前的方式行不通？ #

1. OAuth2方式：依赖手动获取的短期accessToken（1小时过期），Power BI不会自动刷新这个令牌，所以每次过期都得重新部署更新令牌，完全不符合CI/CD的自动化需求。
2. Basic方式：报错是因为你的Azure SQL启用了仅Azure AD认证，而Basic类型是用于SQL账号密码登录的，和AAD认证体系完全不兼容，所以会被直接拒绝。

额外注意事项 #

• 确保你的Azure AD服务主体已经被授予Azure SQL数据库的必要权限（比如db_datareader、db_datawriter，根据仪表板的读写需求分配）
• 服务主体的密钥要定期轮换，严格遵循公司的安全政策
• 确认Power BI服务的网络环境能正常访问你的Azure SQL服务器（比如没有防火墙限制）

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