启用TDS及MFA的Azure Function访问Dynamics CRM认证问题求解

ActiveDirectoryInteractive 认证模式的运行前提是当前环境具备可交互的桌面UI，用来弹出Azure AD登录窗口，完成账号输入、MFA校验、授权确认全流程。你本地运行控制台程序、本地调试Azure Function时，认证弹窗可以直接在你当前操作的电脑上弹出，所以流程能正常跑通。
Azure Function发布后运行在Azure托管的无UI沙箱环境中，既没有承载登录弹窗的交互界面，也无法接收人工输入的认证信息，交互式认证流程会直接卡住直到超时，完全无法正常工作。

你已经明确环境支持服务主体认证，直接替换为无交互的服务主体认证模式即可，全程不需要人工交互，完全适配Azure Function的托管运行环境：

• 前置权限配置
  1. 记录你要用的服务主体的客户端ID（应用ID）、租户ID、客户端密钥，确认密钥在有效期内
  2. 登录Dynamics CRM管理后台，在「安全-应用用户」列表中添加对应客户端ID的应用用户，给这个应用用户分配和你之前本地登录用的XRMDe**@****.com账号一致的安全角色，确保有TDS查询、对应实体的访问权限
• 替换连接字符串
  移除原连接字符串里的交互式认证配置，改为服务主体认证模式，参考写法：

// 服务主体（客户端密钥模式）连接字符串
string ConnectionStringTDS = @"Driver={ODBC Driver 17 for SQL Server};SERVER=*******.crm.dynamics.com;DATABASE=******;Authentication=ActiveDirectoryServicePrincipal;UID=<替换为你的服务主体客户端ID>;PWD=<替换为你的服务主体客户端密钥>;Authority Id=<替换为你的Azure AD租户ID>;";

注意：客户端ID、密钥、租户ID这类敏感凭据不要硬编码在代码里，本地调试存在local.settings.json配置里，发布到Azure后存在Function的「应用程序配置」中，代码通过环境变量读取即可，避免凭据泄露。

• 发布配置注意项
  1. Azure Function托管计划选Windows系（消费计划、专用计划都可以），不要选Linux消费计划——默认Linux镜像未预装ODBC Driver 17 for SQL Server，手动装驱动流程繁琐且容易出兼容问题
  2. Function平台位数配置为64位，和你本地安装的ODBC驱动位数保持一致，避免驱动加载失败

• 不要尝试用任何hack手段在Azure Function里跑交互式认证：Azure沙箱默认拦截所有弹窗类交互流程，就算临时绕过限制，也会因为平台版本迭代随时失效，没有生产可用性
• 如果你的Azure AD开了条件访问策略，记得把Azure Function的出站公网IP加到策略允许列表里，避免认证请求被拦截
• 本地调试时就先换成服务主体连接字符串跑通全流程，确认TDS查询结果符合预期再发布，减少云上排查成本

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