Windows服务中SQL Server Windows身份验证失效问题咨询

首先整理你提供的数据库连接字符串，方便后续参考：

<add name="NuspayTransactionSecurityEntities" connectionString="metadata=res://*/Security.NTPSecurity.csdl|res://*/Security.NTPSecurity.ssdl|res://*/Security.NTPSecurity.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=False;;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" /> 
<add name="NPTransaction" connectionString="metadata=res://*/Transaction.NPTransaction.csdl|res://*/Transaction.NPTransaction.ssdl|res://*/Transaction.NPTransaction.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=False;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" /> 
<add name="CBCommon" connectionString="metadata=res://*/Common.CBCommon.csdl|res://*/Common.CBCommon.ssdl|res://*/Common.CBCommon.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=True;persist security info=False;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient"/> 
<add name="ApplicationServices" connectionString="data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=True;persist security info=False;" providerName="System.Data.SqlClient"/>

问题根源分析 #

你遇到的核心矛盾是运行身份的权限差异：

• IIS Web应用默认使用应用池身份（比如ApplicationPoolIdentity或你指定的域账户），这个账户通常已经被配置为拥有SQL Server的访问权限（可能是你之前手动设置过，或者域环境下自动信任了应用池身份）。
• 而Windows服务默认运行在Local System、Local Service这类本地系统账户下，这些账户无法通过Windows身份验证访问远程SQL Server（你的SQL地址是192.168.10.11，属于远程）——因为远程SQL Server无法识别本地机器的账户，会直接拒绝访问请求。

具体解决方案 #

1. 修改Windows服务的运行账户 #

这是解决问题的核心步骤：

• 打开服务管理器（按下Win+R输入services.msc），找到你的Windows服务，右键选择「属性」。
• 切换到「登录」选项卡，选择「此账户」，输入一个域账户（如果你的机器和SQL Server在同一个域环境下，优先选这个），或者拥有SQL Server登录权限的本地账户（仅适用于SQL Server在本地的场景，这里不推荐）。
• 输入该账户的密码，点击「确定」后重启服务。

2. 为服务账户配置SQL Server权限 #

确保你选择的账户在SQL Server中有合法的访问权限：

• 打开SQL Server Management Studio（SSMS），连接到192.168.10.11的SQL实例。
• 展开「安全性」→「登录名」，右键选择「新建登录名」。
• 在「常规」选项卡，选择「Windows身份验证」，输入服务要使用的域账户（格式：域名\用户名）。
• 切换到「用户映射」选项卡，勾选SP_PROCESSOR数据库，为该用户分配必要的权限（比如db_datareader、db_datawriter，或者根据你的应用实际需求调整）。
• 点击「确定」保存配置。

3. 清理连接字符串中的冗余配置 #

你的CBCommon和ApplicationServices连接字符串里重复了persist security info=True;persist security info=False;，虽然这不是验证失败的直接原因，但建议修正为统一配置，避免潜在问题：
比如CBCommon修正后：

<add name="CBCommon" connectionString="metadata=res://*/Common.CBCommon.csdl|res://*/Common.CBCommon.ssdl|res://*/Common.CBCommon.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=False;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient"/>

ApplicationServices修正后：

<add name="ApplicationServices" connectionString="data source=192.168.10.11;initial catalog=SP_PROCESSOR;persist security info=False;" providerName="System.Data.SqlClient"/>

4. 提前测试账户的SQL访问权限 #

修改服务配置前，你可以先验证账户是否能正常访问SQL：

• 打开命令提示符，用runas命令以目标账户启动cmd：

  runas /user:域名\用户名 cmd
  

• 在新打开的cmd窗口中，执行SQL连接测试命令：

  sqlcmd -S 192.168.10.11 -d SP_PROCESSOR -E
  

如果能成功进入SQL命令行，说明账户权限没问题；如果失败，根据报错信息排查（比如账户无登录权限、网络不通等）。

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