背景（只是相关部分）： 我们有一个大型内联网asp.net 2.0 / 3.5应用程序 Web服务器是AD域上的Windows Server 2003 客户端在Windows上，IE 6-8。 Windows身份验证，具有从Windows标识创建的自定义主体。 Web服务器位于F5 NLB后面，后者将用户转发到特定的Web服务器。 （原因是我们公司的F5与kerberos交易的限制）。 没有系统范围的问题，如丢弃会话，超时或服务器过载，一切都运行良好。
一项功能需要委派 - 我们使用域/网络服务器提供给我们的Kerberos令牌作为经过身份验证的用户连接到网络文件共享。
SPN，ACL等似乎已正确设置。
99.x％的时间，一切正常。我们看到的问题是一次又一次，在刷新时，令牌从kerberos下降到ntlm。我可以在Web服务器的事件日志中看到登录，显示一个调用得到这个：
登录过程：Kerberos 身份验证包：Kerberos
随后的调用（通常在10或20页加载后）得到这个：
登录过程：NtLmSsp 身份验证包：NTLM
任何人都有任何见解可能会使后续的回发有时会变成NTLM吗？
谢谢！
答案 0 :(得分：2)
识别问题所需的所有工具和技术都在Troubleshooting Kerberos Errors中。那份文件从未让我失望过。
NTLM Fallback
你可能会发现 安全日志记录了一个事件 使用NTLM时发生了哪次登录 应该使用Kerberos发生 认证。<强>问题
那里有两个 可能发生这种情况的情况：
- 第一种情况是在哪里 系统尝试使用身份验证 Kerberos协议但它失败了。如 结果，系统尝试 使用NTLM进行身份验证。视窗 Server 2003，Windows XP和Windows 2000使用称为Negotiate的算法 （SPNEGO）谈判哪个 使用身份验证协议。 虽然Kerberos协议是 默认情况下，如果默认失败， 谈判将尝试NTLM - 第二 情况是一个呼吁 谈判返回NTLM是唯一的 协议可用。<强>确认
该 第一种情况会导致a Kerberos身份验证失败了 你可以通过检查来调查 事件日志或数据中的错误 网络监视器捕获的数据包。 两种调查方法都是 本文稍后讨论......