仅单个用户出现IIS连接SQL Server时'NT AUTHORITY\ANONYMOUS LOGON'登录失败错误

针对特定用户（及特定Windows 11机器上的域管理员）出现NT AUTHORITY\ANONYMOUS LOGON登录失败的问题，结合场景（同一域、Windows身份验证+模拟、其他用户正常），核心矛盾是用户凭据能传递到IIS，但无法进一步委派到SQL Server，以下是针对性排查方向：

1. 检查用户AD账户的敏感标记 #

• 打开AD用户和计算机，找到该用户账户，进入「属性」->「账户」选项卡
• 查看「账户选项」中是否勾选了**「敏感账户，不能被委派」**
  • 若勾选，该用户的凭据无法被IIS委派到SQL Server（双重跳场景），会直接降级为匿名登录。取消勾选后测试。

2. 检查用户客户端机器的Kerberos相关配置 #

针对Windows 11机器出现异常的情况，检查以下本地策略：

• 打开「本地安全策略」->「计算机配置」->「Windows设置」->「安全设置」->「本地策略」->「安全选项」
  • 查看**「网络安全: LAN管理器身份验证级别」**：若设置为「仅发送NTLMv2响应/拒绝LM和NTLM」或更低，会强制使用NTLM，而NTLM不支持双重跳，导致凭据无法传递到SQL。建议设置为「协商：尝试Kerberos，然后NTLM」
  • 查看**「网络安全: Kerberos客户端不支持DES加密类型」**：若未启用，而用户AD账户被设置为「使用DES加密类型的账户」，Windows 11会拒绝生成DES票据，导致Kerberos协商失败， fallback到NTLM后双重跳失败。

3. 验证用户客户端的Kerberos票据获取情况 #

在出现问题的Windows 11机器上，执行以下操作：

• 运行cmd，输入klist purge清空现有票据
• 重新访问站点后，输入klist查看票据列表
  • 确认是否存在针对IIS服务器SPN（如HTTP/<IIS服务器名>）的票据
  • 确认是否能获取到SQL Server的SPN（如MSSQLSvc/<SQL服务器名>:1433）的票据
  • 若缺少相关票据，说明Kerberos协商失败，需排查DNS解析（确保IIS/SQL服务器的主机名能被正确解析）或域控制器的Kerberos配置。

4. 检查用户AD账户的加密类型设置 #

• 回到AD用户属性的「账户」选项卡，查看是否勾选了**「使用DES加密类型的账户」**
  • Windows 11默认禁用了DES加密，若用户账户强制使用DES，会导致Kerberos票据生成失败，进而无法完成双重跳，改为匿名登录。取消该勾选后测试。

5. 确认站点的模拟与Kerberos配置（辅助验证） #

虽然其他用户正常，但可快速确认：

• 检查web.config中的身份模拟配置：确保<identity impersonate="true" />正确配置
• 检查IIS站点的Windows身份验证设置：确保启用了「Kerberos」提供程序，且未禁用
• 确认IIS服务器的SPN已正确注册（如setspn -S HTTP/<IIS服务器名> <IIS应用池账户>）——此步骤其他用户正常，大概率配置正确，但可辅助验证。

内容的提问来源于stack exchange，提问作者A and M Dev