IE/IIS集成认证问题
在 IIS 中我有：
http://myserver/myapplicationhttp://myserver/reports
报告应用程序实际上是使用 Windows 身份验证的报告服务。 myapplication 是一个使用表单身份验证的 ASP.NET 应用程序。
服务器在公司域外。如果我首先访问报告并在提示时输入用户和密码（在服务器上创建的本地凭据），我可以访问报告页面，没有问题。如果然后我直接进入应用程序的登录页面并尝试登录，登录页面将刷新而不执行任何操作。这种情况在 IE 6 中总是发生。在 IE 7 中，它会间歇性地发生。在 Firefox 中或 Fiddler 在后台运行时不会发生这种情况，这似乎可以即时解决问题。
我使用wireshark查看发生了什么事，发现IE 6将从reports应用程序获取的Windows身份验证令牌发送到myapp。这是 IE 和 Firefox 之间的唯一区别。 IIS 似乎吓坏了，只是将我到登录页面的 POST 解释为 GET 并返回。
如果我将 Windows 身份验证添加到 IIS 中的应用程序，则一切似乎都可以在任何浏览器上正常工作。
为什么会发生这种情况？ IE 中的错误还是我遗漏了什么？
In IIS I've got:
http://myserver/myapplicationhttp://myserver/reports
The reports app is reporting services in fact which uses windows authentication. myapplication is an asp.net application that uses forms authentication.
The server is outside the company domain. If I access the reports first and type in the user and password(local credentials created on the server) when prompted I can access the reports page, no problems. If then I go straight to my application's login page and try to login, the login page refreshes without doing anything. This always happen in IE 6. In IE 7 it happens intermittently. Does not happen in Firefox or if Fiddler is running in the background which seems to fix the problem on the fly.
I used wireshark to see what's going on and found that IE 6 send the windows authentication token obtained from the reports app to myapp. That was the only difference between IE and Firefox. IIS seems to freak out and simply interpret my POST to the login page as a GET and return.
If I add windows authentication to myapplication in IIS everything seems to work fine with any browser.
Why is this happening? A bug in IE or am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是 IE 中的一个错误，也是 HTTP 上 NTLM/Negotiate（又名集成）身份验证设计中的一个错误。
NTLM/Negotiate 是面向连接的身份验证协议，HTTP 并不是为此而设计的。因此，当您的服务器上的一个页面需要这种身份验证机制时，IE 通常会假设服务器上的其他页面也有相同的要求。
此外，出于性能和安全原因，如果 IE 期望给定 POST 请求的协商/NTLM 质询，那么它将首先发送 0 字节 POST，期望服务器返回 HTTP/401 质询它将对其进行身份验证，然后正确发送 POST 正文。
但是，在您的情况下，不需要集成身份验证的文件夹会获取 0 字节 POST 并显示“嗯，奇怪，0 字节帖子。好的，HTTP/200，这是页面，就好像您使用了 GET 一样。”
因为 IE 永远不会收到它所期望的 401 质询，所以它永远不会真正发送 POST 正文。
（由于 HTTP 连接重用的工作原理，Fiddler 可能会让您有点困惑）。
解决方法是确保如果您在主机上使用集成身份验证，则在任何地方都使用它。
It's sorta a bug in IE, and sorta a bug in the design of NTLM/Negotiate (aka Integrated) authentication over HTTP.
NTLM/Negotiate are connection-oriented auth protocols, which HTTP wasn't really designed for. As a result, when you require this auth mechanism for one page on your server, IE will typically assume that other pages on the server have the same requirement.
Furthermore, for performance and security reasons, if IE expects a Negotiate/NTLM challenge for a given POST request, then it will first send a 0 byte POST, expecting the server to return a HTTP/401 challenge to which it will authenticate and then properly send the POST body.
However, in your case, the folder which doesn't require Integrated auth gets the 0 byte POST and says "Hrm, weird, a 0 byte post. Okay, HTTP/200, here's the page as if you'd used GET."
Because IE never gets the 401 challenge it expects, it never actually sends the POST body.
(Fiddler may confuse you a bit due to how HTTP connection reuse works).
The workaround is to ensure that if you're using Integrated auth on the host, use it everywhere.