首次异步查询后丢失应用程序池身份问题求助

这种「部分查询正常、部分突然抛出Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'」的问题我排查过好几次，核心都是身份凭据在跨服务器传递时中断了。结合你的场景（IIS 7.5上的.NET API、应用池用AD域账户、SQL在另一台服务器），下面是几个最可能的原因和对应的排查方案：

1. 双跳问题（Kerberos约束委派未配置） #

这是最常见的诱因。你的API在IIS上运行是第一跳，API访问远程SQL服务器是第二跳。默认NTLM协议不支持跨服务器的身份传递（双跳），只有Kerberos配合约束委派才能让域账户身份从IIS服务器传递到SQL服务器。

• 怎么确认：查看SQL服务器的登录日志，成功的查询会显示登录名是你的应用池域账户（比如DOMAIN\AppPoolAccount），而失败的查询大概率是Kerberos协商失败， fallback到NTLM后触发匿名登录。
• 解决办法：在Active Directory用户和计算机中找到你的应用池域账户，打开「属性」→「委派」选项卡，选择「信任此用户委派到指定服务」，然后添加SQL服务器的MSSQLSvc服务（要包含SQL服务器的主机名和端口）。

2. 连接字符串配置不一致 #

部分查询可能用了错误的身份验证配置，导致没有使用应用池的域账户。

• 排查点：检查所有失败查询对应的数据库连接字符串，确保设置了Integrated Security=True（或Trusted_Connection=True），并且没有硬编码User ID和Password参数。如果你的API用了多个数据库上下文，要逐个确认每个上下文的连接字符串都配置正确。

3. ASP.NET模拟设置冲突 #

如果你的API启用了ASP.NET模拟，但模拟配置不当，可能会覆盖应用池的身份，导致身份传递中断。

• 排查点：在IIS管理器中找到你的API站点，进入「身份验证」功能，查看「ASP.NET模拟」是否启用。如果启用了，检查模拟的用户是否是你的应用池域账户，或者是否有额外的权限限制。
• 解决办法：如果不需要模拟功能，直接禁用ASP.NET模拟；如果必须启用，确保模拟用户拥有足够的权限，并且配合Kerberos约束委派配置。

4. SQL服务器的SPN配置错误 #

Kerberos认证依赖正确的服务主体名称（SPN）。如果SQL服务器的SPN没有正确注册，Kerberos协商会失败，进而触发NTLM fallback和双跳失败。

• 排查命令：在域控制器或SQL服务器上执行setspn -L SQLServerHostName，查看是否存在MSSQLSvc/SQLServerHostName:Port和MSSQLSvc/SQLServerHostName.Domain.com:Port这两个条目（Port是你的SQL服务端口，默认1433）。
• 解决办法：如果缺少SPN，用域管理员账户执行setspn -A MSSQLSvc/SQLServerHostName:Port DOMAIN\SQLServiceAccount来注册（SQLServiceAccount是运行SQL服务的域账户）。

5. 查询涉及高权限/跨资源访问 #

某些失败的查询可能涉及链接服务器、跨数据库访问，或者访问了需要特殊AD权限的对象，这些场景会额外触发身份传递的限制。

• 排查点：对比成功和失败的查询语句，看失败的查询是否用到了链接服务器、跨库查询，或者访问了需要特定AD组权限的表/存储过程。
• 解决办法：确保应用池域账户对这些额外资源拥有足够的访问权限；如果涉及链接服务器，还要给应用池账户配置针对链接服务器的Kerberos委派。

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