ASP.NET应用：IIS域账户应用池模拟失效，默认标识正常？

这个问题的核心是Kerberos委派的主体不匹配，加上域服务账户的委派权限未正确配置，导致双跳身份传递失败。咱们先拆解为什么两种应用池身份表现不同，再给出具体的解决步骤：

一、为什么AppPoolIdentity能正常工作？ #

当应用池使用默认的AppPoolIdentity时，它实际对应的是Web服务器的计算机账户（格式为DOMAIN\你的服务器名$）。你之前已经在Web服务器和SQL服务器之间配置了约束委派，本质上是给这个计算机账户授予了委派用户身份到SQL Server的权限，所以Kerberos票据能正常传递，模拟用户访问数据库时身份能正确识别。

二、域服务账户模拟失效的原因 #

换成域服务账户后，委派的主体从服务器计算机账户变成了域服务账户本身，但你之前的委派配置并没有覆盖这个域服务账户，导致：

1. 域服务账户没有被AD允许委派用户身份到SQL Server
2. Kerberos无法将当前登录用户的身份票据传递到SQL服务器，最终只能以匿名身份尝试登录，抛出NT AUTHORITY\ANONYMOUS LOGON错误

三、具体解决步骤 #

1. 给域服务账户配置约束委派 #

打开AD用户和计算机控制台，找到你的域服务账户：

• 右键点击账户 → 属性 → 切换到「委派」标签
• 选择「信任此用户作为委派到指定服务（仅限Kerberos）」
• 点击「添加」→ 选择「用户或计算机」→ 找到你的SQL服务器
• 在可用服务中，添加MSSQLSvc（包含带1433端口和不带端口的两个条目），确认保存

2. 开启应用池的「加载用户配置文件」 #

在IIS管理器中：

• 找到你的应用池 → 右键 → 高级设置
• 定位到「进程模型」→ 将「加载用户配置文件」设置为True
• 这个设置能确保Kerberos票据可以正确存储和传递，避免身份模拟时上下文丢失

3. 验证Kerberos身份验证是否生效 #

在你的Web Forms应用中临时添加代码，检查当前的身份验证类型：

// 在某个页面的后台代码中输出
Response.Write("身份验证类型：" + Request.ServerVariables["AUTH_TYPE"]);

如果输出是Negotiate，说明Kerberos生效；如果是NTLM，需要给域服务账户注册HTTP SPN：

# 替换为你的域名和服务账户名
setspn -S HTTP/你的Web应用域名 DOMAIN\你的域服务账户名

（比如你的Web应用域名是webapp.company.com，服务账户是DOMAIN\WebSvcAcct，就执行setspn -S HTTP/webapp.company.com DOMAIN\WebSvcAcct）

4. 确认SQL Server的登录权限 #

确保当前登录的域用户在SQL Server中已经被授予对应的登录权限和数据库访问权限，避免因为权限不足导致的登录失败（虽然这里报错是匿名，但也可以顺便排查）

四、额外注意点 #

• 不要同时开启「模拟身份验证」，你已经禁用了这一点是正确的，因为WindowsIdentity.RunImpersonated是代码层面的模拟，和IIS的模拟模块不要冲突
• 配置委派后，可能需要重启IIS应用池甚至Web服务器，让配置生效

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