为什么使用 iis 7.5 / windows 7 / 的 asp.net 应用程序的 Windows 身份验证/模拟失败
我正在解决为什么无法通过配置为 Windows 身份验证和模拟的 ASP.Net 站点上的登录对话框的问题。
我有一个 ASP.Net 2.0 应用程序，我正在尝试将其部署在带有 IIS 7.5 的 Windows 7 上。我创建了一个新站点，并将其绑定到本地主机和完全限定的域名。 FQDN 位于我的主机文件中，并被重定向到 127.0.0.1
该站点还使用我创建的 AppDomain 运行，具有集成管道模式，并且进程模型标识设置为 ApplicationPoolIdentity。
Web.config 包括以下内容：
<trust level="High" />
<authentication mode="Windows" />
<authorization>
<deny users="?"/>
</authorization>
<identity impersonate="true"/>`
站点目录上的 ACL 设置为“所有人”（完全控制 - 用于测试）。 应用程序池虚拟帐户（Windows 7 事物）也设置为完全控制站点的物理目录。
IIS 身份验证启用了 ASP.Net 模拟并启用了 Windows 身份验证。
当我作为本地主机连接到该站点时，它允许我通过登录提示并顺利加载应用程序。
当我作为此站点/IP/端口的主机标头绑定中设置的 FQDN 连接到该站点时，我无法通过登录提示。单击取消会生成 http 401.1 错误页面。
为什么？
I'm troubleshooting why I can't get past the login dialog on an ASP.Net site configured for Windows Authentication and Impersonation.
I have an ASP.Net 2.0 application and I'm trying to deploy it on Windows 7 with IIS 7.5. I've created a new site, and bound it to localhost and a fully qualified domain name. the FQDN is in my hosts file, and is redirected to 127.0.0.1
The site is also running with an AppDomain I created, with integrated pipeline mode, and the process model identity is set to ApplicationPoolIdentity.
Web.config includes the following:
<trust level="High" />
<authentication mode="Windows" />
<authorization>
<deny users="?"/>
</authorization>
<identity impersonate="true"/>`
ACL on the directory for the site is set to Everyone (Full Control - For testing).
The Application Pool virtual account (Windows 7 thing) is set to full control on the physical directory for the site also.
IIS authentication has ASP.Net impersonation enabled and Windows Authentication enabled.
When I connect to the site as localhost, it permits me to get past the login prompt and the application loads without incident.
When I connect to the site as the FQDN set in the host headers bindings for this site/ip/port, I cannot get past the login prompt. Clicking cancel generates a http 401.1 error page.
Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题的答案将是一种称为身份验证环回检查的安全功能，该功能早在 Windows 2003 SP1 中就已引入，如下所示： http://support.microsoft.com/kb/926642
我试图使用 /etc/hosts 文件中定义的指向 127.0.0 的主机标头连接到我的 iis 主机标头实例.0.1，在运行 iis 的计算机上登录时 - 这是环回场景。
它会在各种情况下困扰您，例如这个（http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx) 或这个谷歌的伤害世界 (http://www.google.ca/search?q=authentication+loopback+check&ie=utf-8&oe=utf -8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)
该修复涉及一些简单的注册表编辑工作：http://blogs.bluethreadinc.com/thellebuyck/archive/2008/ 10/30/401.1-error-when-accessing-sharepoint-from-server.aspx
我也不需要针对我的情况启用模拟，所以我禁用了它，现在我可以使用我的伪造的 FQDN 进行连接本地和远程
and the answer for this one is going to be a security feature known as the authentication loopback check, introduced way back in Windows 2003 SP1, as per: http://support.microsoft.com/kb/926642
i was trying to connect to my iis host headers instance using a host header defined in my /etc/hosts file as pointing to 127.0.0.1, while logged in at the machine running iis - this is the loopback scenario.
it bites you in various contexts, such as this (http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx) or this world of hurt in google (http://www.google.ca/search?q=authentication+loopback+check&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)
THE FIX involves some simple regedit work: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx
i also did not need to enable impersonation for my situation, and so i disabled that, and now i can connect using my faked fqdn both locally and remotely
Velvet 提供的 URL 已关闭。我在 archive.org 上找到了一个缓存版本：
“
从服务器访问 SharePoint 时出现 401.1 错误
过去，我在设置 SharePoint 环境（供内部开发使用和客户使用）时多次遇到此问题，因此我认为是时候写一篇有关此问题的博客文章了。如果您在 Windows Server 2003 SP1 或更高版本上运行 SharePoint Server 2007 或 WSS 3.0，并且尝试使用服务器本身的主机标头（即主机文件指向 Portal.mydomain.com）访问 SharePoint 网站，则会遇到身份验证问题至 127.0.0.1）。此问题是 Microsoft 在 Windows Server 2003 SP1 及更高版本中内置的环回安全检查的结果。环回检查的目的是消除拒绝服务攻击，但它会导致从服务器本地访问 SharePoint 网站时出现问题。在典型的生产环境中，这通常不是问题，因为您很少从前端 Web 服务器本身访问 SharePoint 站点（除了中央管理之外）。然而，我确实有物理和虚拟开发环境，其中所有活动都从服务器进行，因此这可能会导致一些胃痛，除非您之前已经解决过这个问题。您可以阅读详细的知识库文章：KB926642 & KB896861。以下是如何解决该问题的概述。我通常禁用环回检查，但不建议在生产服务器环境中这样做。
方法一：关闭认证环回检查
通过将
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa注册表子项中的 DisableLoopbackCheck 注册表项设置为 1，重新启用 Windows Server 2003 中存在的行为。设置DisableLoopbackCheck注册表项 1、在客户端计算机上执行以下步骤：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaDisableLoopbackCheck，然后按 Enter。注意 您必须重新启动服务器才能使此更改生效。默认情况下，Windows Server 2003 SP1 中的环回检查功能处于打开状态，并且DisableLoopbackCheck 注册表项设置为0（零）。当您禁用身份验证环回检查并打开 Windows Server 2003 服务器以对 NTLM 进行中间人 (MITM) 攻击时，安全性会降低。
方法 2：创建可在 NTLM 身份验证请求中引用的本地安全机构主机名
为此，请对客户端计算机上的所有节点执行以下步骤：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0BackConnectionHostNames，然后按 Enter。BackConnectionHostNames，然后单击“修改”。注意 在单独的行中键入每个主机名。
注意 如果
BackConnectionHostNames注册表项以 REG_DWORD 类型存在，则必须删除BackConnectionHostNames注册表项。7. 退出注册表编辑器，然后重新启动计算机。
“
来自： http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx，2009 年 6 月 5 日
The URL provided by Velvet is down. I found a cached version on archive.org:
"
401.1 Error When Accessing SharePoint From Server
I ran into this issue several times in the past in setting up SharePoint environments (for both internal development use and customers) so I figured it was time to write a blog post about it. If you are running SharePoint Server 2007 or WSS 3.0 on Windows Server 2003 SP1 or later you will run into authentication issues if you are trying to access a SharePoint site using host headers from the server itself (i.e. host file has portal.mydomain.com pointed to 127.0.0.1). This issue manifests itself as the result of a loop back security check that Microsoft built in to Windows Server 2003 SP1 and later. The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server. In a typical production environment this is typically not a problem since you rarely access SharePoint sites (besides central admin) from a front end web server itself. However I do have physical and virtual development environments where all activities take place from the server, so this can cause some heartburn unless you have worked through the issue before. You can read the detailed KB article at KB926642 & KB896861. Here is a rundown of how to fix the problem. I typically disable the loopback check however this is not recommended for production server environments.
Method 1: Disable the authentication loopback check
Re-enable the behavior that exists in Windows Server 2003 by setting the DisableLoopbackCheck registry entry in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsaregistry subkey to 1. To set theDisableLoopbackCheckregistry entry to 1, follow these steps on the client computer:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaDisableLoopbackCheck, and then press ENTER.DisableLoopbackCheck, and then click Modify.Note You must restart the server for this change to take effect. By default, loopback check functionality is turned on in Windows Server 2003 SP1, and the DisableLoopbackCheck registry entry is set to 0 (zero). The security is reduced when you disable the authentication loopback check, and you open the Windows Server 2003 server for man-in-the-middle (MITM) attacks on NTLM.
Method 2: Create the Local Security Authority host names that can be referenced in an NTLM authentication request
To do this, follow these steps for all the nodes on the client computer:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0BackConnectionHostNames, and then press ENTER.BackConnectionHostNames, and then click Modify.Note Type each host name on a separate line.
Note If the
BackConnectionHostNamesregistry entry exists as a REG_DWORD type, you have to delete theBackConnectionHostNamesregistry entry.7. Exit Registry Editor, and then restart the computer.
"
From: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx on June 05 2009