你遇到的是Windows集成身份验证的典型场景——这种验证方式依赖当前运行Excel的Windows用户身份，而非在连接字符串里输入账号密码，所以单纯修改连接字符串肯定没用。下面给你几个落地的解决方案，按易到难排序：

方案1：用RunAs让用户以通用账号启动Excel（最直接） #

这是最简单的处理方式，让整个Excel进程都在通用Windows账号下运行，VBA的数据库连接会自动继承这个账号的身份：

• 让用户打开命令提示符，输入这条命令（把DOMAIN\通用账号换成你们的实际账号，Excel路径根据Office版本调整）：

  runas /user:DOMAIN\通用账号 "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE"
  

• 回车后会弹出窗口要求输入通用账号的Windows密码，输入后打开的Excel就带着该账号的权限了，你的原有VBA代码无需修改，直接就能完成数据刷新。

方案2：确认VBA连接字符串的Windows身份验证格式 #

先检查你的连接字符串是否为标准的Windows集成验证写法，正确格式如下（替换实际的服务器和数据库名）：

Dim conn As ADODB.Connection
Set conn = New ADODB.Connection
conn.ConnectionString = "Provider=SQLOLEDB;Data Source=你的SQL服务器地址;Initial Catalog=目标数据库名;Integrated Security=SSPI;"
conn.Open

这里的Integrated Security=SSPI就是指定使用当前Windows用户身份验证，只要Excel是用通用账号启动的，这个连接就能正常生效。

方案3：进阶方案（如果用户不能直接用RunAs） #

如果公司政策不允许用户切换账号登录，可以考虑这两个方向：

• 在SQL Server上创建专用的SQL登录账号，仅赋予它读取所需数据的最小权限，然后把该账号的密码写入连接字符串（记得用VBA加密工具给代码加密，避免密码泄露）；
• 将数据拉取逻辑放到SQL Server代理作业中，定时刷新到一个中间表，用户的VBA只需读取这个中间表，无需直接连接源数据库，以此避开身份验证问题。

关键注意点 #

• 无论采用哪种方案，都要确保通用Windows账号已在SQL Server中被授权：在SQL Server的「登录」列表里添加该账号，分配对应数据库的访问和读取权限；
• 绝对不要把通用账号的Windows密码硬编码到VBA里，Windows身份验证的核心就是依赖系统账号权限传递，硬编码密码会带来极大的安全风险；
• 如果是域环境，要确保通用账号是域账号，且拥有访问SQL Server所在网络的权限。

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