ASP.net kerberos 偶尔下降到 NTLM
背景（仅相关部分）： 我们有一个大型 Intranet asp.net 2.0/3.5 应用程序。
Web 服务器是 AD 域上的 Windows Server 2003。
客户端使用 Windows、IE 6-8。 Windows 身份验证，具有从 Windows 身份创建的自定义主体。 Web 服务器位于 F5 NLB 后面，F5 NLB 将用户转发到特定的 Web 服务器。 （其原因是我们公司的 F5 与 kerberos 交易的限制）。 不存在系统范围的问题，例如会话丢失、超时或服务器超载，一切都运行良好。
其中一项功能需要委派 - 我们使用域/Web 服务器提供给我们的 Kerberos 令牌作为经过身份验证的用户连接到网络文件共享。
SPN、ACL 等似乎已正确设置。
99.x% 的情况下，一切正常。我们经常看到的问题是，在刷新时，令牌会从 kerberos 下降到 ntlm。我可以在 Web 服务器的事件日志上看到登录信息，显示一个调用收到此信息：
登录过程：Kerberos 身份验证包：Kerberos
以及后续调用（通常在 10 或 20 个页面加载后）获取：
登录过程：NtLmSsp 身份验证包：NTLM
任何人都知道什么可能导致后续回发有时会进入 NTLM？
谢谢！
Background (just the relevant pieces):
We have a large intranet asp.net 2.0/3.5 app.
Web servers are Windows Server 2003 on an AD domain.
Clients are on Windows, IE 6-8.
Windows Authentication, with a custom principal created from the Windows Identity.
Web servers sit behind an F5 NLB which forwards the user to a specific web server. (The reason for this is a limitation w/ our company's F5 dealing w/ kerberos).
There are no system wide problems like dropping sessions, or timeouts, or overloaded servers, everything's running fine in general.
One piece of functionality requires delegation - we are connecting to a network file share as the authenticated user, using the Kerberos token given to us by the domain/web server.
SPNs, ACLs, etc, seem to be set up properly.
99.x percent of the time, it all works. The problem we're seeing is every now and again, on a refresh, the token drops from kerberos down to ntlm. I can see the login on the web server's event log showing one call getting this:
Logon Process: Kerberos
Authentication Package: Kerberos
And a subsequent call (usually after 10 or 20 page loads) getting this:
Logon Process: NtLmSsp
Authentication Package: NTLM
Anyone have any insight as to what might be making a subsequent postback sometimes go NTLM?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
识别问题所需的所有工具和技术都位于 Kerberos 错误故障排除。那份文件从来没有让我失望过。
All the tools and techniques you need to identify the issue are in Troubleshooting Kerberos Errors. That document never failed me.