通过C#执行带EXECUTE AS的存储过程访问链接服务器失败（SSMS正常）

核心差异点 #

SSMS和C#应用的执行环境、会话上下文存在隐性区别，导致EXECUTE AS模拟的PROXY_USER在访问链接服务器时身份验证失败，具体分以下几种可能：

1. 会话SET选项不一致 #

SSMS默认启用了一系列SET选项（比如ANSI_NULLS、ANSI_WARNINGS等），这些选项会影响SQL Server对模拟身份的权限判断。但C#客户端的默认SET配置和SSMS不一致，触发了MSDASQL提供者的验证拒绝。

• 处理：在C#调用存储过程前，先执行与SSMS一致的SET命令，比如：

  SET ANSI_NULLS ON;
  SET ANSI_PADDING ON;
  SET ANSI_WARNINGS ON;
  SET ARITHABORT ON;
  SET CONCAT_NULL_YIELDS_NULL ON;
  SET QUOTED_IDENTIFIER ON;
  

2. 应用运行账户的权限限制 #

如果你的C#应用运行在Windows服务、IIS应用池这类账户下，而SSMS是用你的桌面用户打开的，两者的运行环境权限不同。MSDASQL可能允许桌面账户的模拟身份访问链接服务器，但服务账户没有对应权限。

• 处理：临时将C#应用切换为与SSMS相同的账户运行测试，或者给应用的运行账户添加访问链接服务器相关资源的权限。

3. 连接池干扰了模拟上下文 #

C#默认使用连接池复用数据库连接，这可能导致之前会话的上下文残留，干扰EXECUTE AS的身份有效性。而SSMS每次执行都是全新会话，不会存在这个问题。

• 处理：要么在连接字符串中添加Pooling=false禁用连接池（仅测试用，生产环境谨慎操作），要么在存储过程执行完毕后显式重置上下文：

  REVERT;
  

4. 数据库TRUSTWORTHY属性未开启 #

如果NS_TEST数据库未启用TRUSTWORTHY属性，EXECUTE AS的用户可能无法访问外部链接服务器资源。虽然SSMS能正常执行，但C#的会话触发了更严格的权限校验。

• 处理：执行以下命令开启该属性：

  ALTER DATABASE NS_TEST SET TRUSTWORTHY ON;
  

5. MSDASQL提供者的配置差异 #

MSDASQL分32位和64位版本，若SSMS使用的是32位提供者，而C#应用是64位，两者的配置可能不一致。另外，提供者的Allow inprocess选项未启用也会影响身份验证。

• 处理：
  • 打开SQL Server配置管理器，找到MSDASQL提供者，检查Allow inprocess是否启用；
  • 确保C#应用的位数与SSMS使用的提供者位数一致。

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