如何检测模拟用户时发生 kerberos 身份验证延迟的位置？
在模拟另一个域用户进行文件系统访问的应用程序中，从调用 WindowsIdentity.Impersonate 到实际完成该用户的身份验证，我们遇到了 2 秒的延迟。这只能在生产计算机 (Windows Server 2008) 上重现，而不能在我们的开发计算机 (Windows 7) 上重现。通过使用 Wireshark 分析网络流量，我们验证了延迟发生在 Kerberos 身份验证发生之前 - 身份验证只花费一小部分时间，而延迟发生在之前。
有哪些工具可以帮助查明延迟的确切位置/原因？谢谢！
突破：这只发生在生产计算机上运行的 64 位进程中（针对 x86 编译的相同代码库运行时不会出现生产延迟）。但为什么？更多研究...
（相关信息将被添加）。
In an application that impersonates another domain user for file system access, we're experiencing a 2 second delay from when WindowsIdentity.Impersonate is called to when the authentication for that user is actually done. This is only reproducible on the production machine (Windows Server 2008), not on our development machines (Windows 7). We verified that the delay happens before Kerberos authentication takes place by analyzing network traffic using Wireshark - the authentication only takes a fraction of the time, while the delay occurs beforehand.
What tools exist that will help to pinpoint the exact location/cause of this delay? Thanks!
Breakthrough: This only happens in a 64-bit process running on the production machine (the same code base compiled targeting x86 runs with no delays on production). But why? More research...
(Additional information will be added as it becomes relevant).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您尚未使用它们，那么您几乎肯定会受益于 中的一些工具Windows SysInternals 工具套件。 进程监视器可能是一个好的开始。基本思想是跟踪 Windows 和您的应用程序正在做什么，然后看看会发生什么。
您是否已将调试器附加到进程中？
另一件要做的事情是确定生产机器和开发机器之间的其他差异。是否正在使用不同版本的库？配置怎么样？如果您有生产服务器的备份，您可以在那里重现问题吗？
If you are not already using them, you'd almost certainly benefit from some of the tools in the Windows SysInternals suite of tools. Process Monitor might be a good start. The basic idea is to trace what Windows and your application are doing and see what turns up.
Have you attached a debugger to the process?
The other thing to do is to identify other differences between the production and development machines. Are there different versions of libraries in use? What about configuration? If you have a backup of your production server, can you recreate the problem there?