Azure Analysis Services是否支持服务主体登录SQL Azure以替代SQL用户？

我之前刚好帮团队实现过这个场景，踩过几个小坑，分享下具体的步骤和注意事项，应该能解决你的问题：

1. 先搞定服务主体的SQL Azure权限 #

首先你得有一个Azure AD服务主体（如果还没有，直接在Azure Portal里创建一个就行），然后给它分配SQL Azure的访问权限：

• 登录SQL Azure的查询编辑器，执行以下SQL语句，把服务主体添加为数据库用户并赋予必要的权限（比如db_datareader，根据你的业务需求调整）：

  CREATE USER [你的服务主体显示名称/应用程序ID] FROM EXTERNAL PROVIDER;
  ALTER ROLE db_datareader ADD MEMBER [你的服务主体显示名称/应用程序ID];
  

  这里的名称可以用服务主体的显示名称或者应用程序ID（GUID），只要和Azure AD里的对应上就行。

2. 调整M语言的连接字符串配置 #

你之前用Authentication=ActiveDirectoryPassword出错是正常的——这个认证方式是给普通Azure AD用户用的，服务主体得用专门的认证类型：

• 把认证方式改成ActiveDirectoryServicePrincipal，然后填入服务主体的应用程序ID和客户端密码，正确的M代码示例如下：

  let
      Source = Sql.Database("your-sql-server-name.database.windows.net", "your-db-name", 
          [
              Authentication="ActiveDirectoryServicePrincipal",
              UserID="服务主体的应用程序ID（GUID）",
              Password="服务主体的客户端密码"
          ])
  in
      Source
  

  注意：UserID必须填服务主体的应用程序ID，不能用显示名称，否则会认证失败。

3. 额外的检查项 #

• 确认SQL Azure的防火墙规则允许Azure Analysis Services访问：要么把AS的公网IP加入防火墙，要么直接开启“允许Azure服务和资源访问此服务器”的选项，避免被防火墙拦截。
• 如果是用Tabular Editor或者SSDT部署模型，确保部署账号有Azure Analysis Services的管理员权限，不然模型可能无法正常加载凭据。

常见错误排查 #

• 要是还是报错，先检查服务主体的密码是否过期，应用程序ID有没有填错
• 也可以在SQL Azure的日志里查看认证失败的具体原因，定位问题会更高效

内容的提问来源于stack exchange，提问作者Nick.Mc