我为我的组织开发了几个使用集成身份验证的内部网站。最终，我们希望这些网站可供拥有加入域的计算机的外部用户访问。这些网站在内部网络上的域计算机上按预期运行。当我将笔记本电脑带回家并尝试访问这些网站时，问题就出现了。
IIS 仅对这两个站点启用了集成身份验证。当我使用 IE8 浏览该站点时，我收到用户名/密码提示，要求输入域凭据。我可以输入这些，它就可以工作，但目标是使用缓存令牌进行集成身份验证。
接下来我推断，除非站点受信任，否则 IE 不会响应集成身份验证请求（NTLM 是正确的术语吗？）。我尝试将站点添加到受信任的站点，但得到的行为与之前相同。然后我将站点添加到本地 Intranet 站点，这时事情变得奇怪了。我从 IE 获得一个通用错误页面，没有错误代码或任何东西。
只是为了好玩，我装了 Firefox（我之前已经设置为使用集成身份验证），并将这个新网站添加到网络.自动-ntlm-auth.trusted-uris。令我惊讶的是，我能够毫无问题地加载页面，并且看到了我所期望的内容（包括验证集成身份验证是否有效）。
我现在有点困惑，因为我真的不知道接下来该怎么做。我希望你们中的一些人可以提供一些见解。
更新 05/11/10 我按照下面的建议使用 Fiddler，发现 Firefox 和 IE 处理页面请求的方式存在一些差异。当我测试 Internet Explorer 时，它发出一个请求，遇到 401.2（服务器配置错误）并死机。发生这种情况时没有安全日志条目。Firefox 最初遇到同样的错误，但随后发送另一个请求并且身份验证成功。
请记住，最初的测试都是在网络外部进行的，我查看了 IE8 在内部进行的一次成功身份验证，它的行为似乎与 Firefox 内部和外部的行为相同。初始请求遇到 401.2，然后发送另一个请求并遇到 401.1（质询？），然后是 200（成功）。
因此，问题似乎是，当从网络外部访问“内部网”站点时，IE8 会出现 401.2 错误，然后在它应该（按照其他浏览器的标准）继续进行身份验证过程时死机。
有人可以验证我描述的 Fiddler 活动吗？
答案1
在我看来，你正成为 IE8 中一个“漏洞”的受害者，就像在此处向 Microsoft 报告和此处详细讨论。
我怀疑如果您使用AdsUtil.vbs脚本将受影响目录上的身份验证设置为“NTLM”而不是默认的“Negotiate,NTLM”，问题可能会消失。
您可以通过使用 Wireshark（或您最喜欢的嗅探器）监视客户端计算机并观察它在尝试访问站点时是否尝试为域控制器执行 NetBIOS 广播名称解析来验证是否看到此行为。
关于我所讨论的 NTAuthenticationProviders 值的一些背景信息来自 Microsoft KB215383。对于 IIS6，如果未定义该值，则 IIS 会将其视为“Negotiate,NTLM”。我猜你是在默认设置下运行。
您可以使用adsutil.vbs脚本（默认情况下安装在 %SystemDrive%\Inetpub\AdminScripts 中）检查此值。使用以下命令检查计算机上第一个网站的值（显然，请更改此示例中的路径以适合您的实际应用）：
cscript adsutil.vbs GET W3SVC/1/Root/NTAuthenticationProviders
请记住 - 如果未定义该值，则 IIS6 将使用其编译的默认设置“Negotiate,NTLM”。
要更改计算机上第一个网站的根目录的 NTAuthenticationProviders 值，请使用以下命令：
cscript adsutil.vbs SET W3SVC/1/Root/NTAuthenticationProviders "NTLM"
Microsoft 建议您在设置值“took”后通过再次查询来验证该值。
答案2
您是否有权访问 IIS 服务器的安全日志？如果可以，这将帮助您找出集成身份验证在 IE8 中失败的原因。如果您无权访问日志，则可以使用 WebFiddler 获取流量的客户端视图，这样您就可以比较 IE8 和 FireFox 之间的 HTTP 身份验证流量。