简洁版本：
对于具有 Windows 身份验证的 IIS 7.5 Web 应用程序，最终用户是否需要具有读取文件访问权限？
长版：
我有一个使用 Windows 身份验证的 Intranet ASP.NET Web 应用程序。它安装在数十家不同的公司，通常验证工作正常：用户导航到该站点，例如http://appserver/MyApp，该应用程序识别他们登录的身份并相应地显示页面。我刚刚在一个新客户端上安装了它，遇到了一个问题：
例如，当连接到时，系统会http://appserver/MyApp提示我输入 Windows 凭据，但在输入它们后，我会反复提示。多次重新输入凭据后，我看到一个 401 错误页面，上面写着“401 - 未经授权：由于凭据无效，访问被拒绝。”。因此，它不仅没有通过我的身份，而且即使输入用户名和密码，它仍然拒绝访问。
向应用程序的最终用户授予读取和执行权限可以解决此问题，但我认为这根本没有必要。
在 Windows 应用程序事件日志中，有一条消息“请求的文件授权失败”以及线程帐户名称：NT AUTHORITY\NETWORK SERVICE 和用户：[正确的工作站用户的域帐户]。这表明文件访问是使用用户的身份执行的，而不是网络服务的 AppPool 身份。果然，如果我授予最终用户对应用程序目录的读取和执行权限（我没有尝试只读），那么一切正常：当用户浏览到该站点时，他们会自动进行身份验证，而不是提示，并且网站正确识别自己的身份！因此，我的解决方案是向应用程序目录中的每个人授予读取和执行权限...
这似乎很奇怪。据我记得，我以前在 IIS 7.5 中从来不需要这样做，而且在 IIS 6 或 IIS 7 中绝对不需要这样做。这是 IIS7.5 的新事物吗？文档说默认情况下模拟是关闭的。我在 web.config 中添加了一个元素以确保删除了网络服务以外的文件权限，但问题仍然存在。
有什么想法吗？对于 IIS 7.5 上的 Windows Authenticated 站点，最终用户需要对 Web 服务器文件的文件权限是否正常？
一些相关细节：
- 网络服务对应用文件夹具有完全控制文件权限。
- 当从服务器本身连接时，我被提示输入凭据，但在输入凭据后，我已通过身份验证并且应用程序正常工作，包括显示我的 Windows 登录名以及连接和检索数据库中的数据。我后来确定它正在提示输入凭据，因为
http://localhost它位于受信任的站点中，因此未被识别为 Intranet 区域，因此没有传递身份。我还确定它作为此用户身份工作，因为它是具有文件权限的管理员用户。 - Web 服务器正在运行 Windows Server 2008 R2 / IIS 7.5。在我安装它之前，它上面没有 IIS。我安装了默认功能以及 Windows 身份验证、ASP.NET 以及可能的其他一些项目。我安装的一个使用 IIS、匿名身份验证和 .net 2.0 的单独 WCF 应用程序在该 Web 服务器上运行良好。
- 应用程序安装过程是文件的手动副本、IIS 应用程序池和 Web 应用程序的创建、更新连接字符串等。
- 我检查了 IE 安全设置。它将服务器识别为 Intranet 区域，并选择了“仅在 Intranet 区域中自动登录”选项。同样在“高级设置”中，“启用集成 Windows 身份验证”选项已被选中。
- 安装 IIS 后，我运行
aspnet_regiis -i了 .net 2.0 和aspnet_regiis -iru.net 4.0。 - 我的应用程序禁用了匿名身份验证，并启用了 Windows 身份验证。
- 该应用程序在 ASP.NET v4 上运行，但我安装的另一个应用程序在运行 ASP.NET v2 时遇到了同样的问题。
- 该应用程序使用 Identity = Network Service 和 32 位模式运行。
- 数据库连接字符串包括
Trusted Connection=True和数据库权限被授予 Web 服务器帐户，[domain]\[server]$例如DGM\MyServer$。 - 在 IIS > 身份验证 > Windows 身份验证 > 提供程序中，列表首先是协商，然后是 NTLM。我尝试重新排序，所以 NTLM 是第一位的。
- 在 Windows 安全事件日志中有一系列 Microsoft Windows 安全审核事件：登录和注销。他们表示登录成功并显示工作站用户的用户 ID。这是从我从另一个工作站连接并在几次尝试后收到 401 Unauthorized 时开始的。
我看到有人在这里报告了这个问题，但没有解决方案。最初我在ASP中发布，然后在IIS论坛上发布，到目前为止还没有答案。
更新： 这篇 msdn 文章说
当启用 Windows 身份验证但禁用模拟时，ASP.NET使用从浏览器发送的凭据在文件授权模块中执行文件访问检查（我的重点） . 不需要启用模拟，因为 FileAuthorizationModule 模块确保请求用户被允许对资源进行读取访问或写入访问，具体取决于执行请求之前的请求动词（例如，GET 或 POST）。此行为适用于输入托管代码的任何请求。在早期版本的 ASP.NET 中，访问基于诸如“Default.aspx”之类的 URI 的文件会触发访问检查。在 ASP.NET MVC 应用程序中，通常使用无扩展名 URL 执行对资源的访问，此检查通常不适用，因为没有要检查的物理文件。在这种情况下，FileAuthorizationModule 类回退到检查文件夹的访问控制列表 (ACL)。
这确实表明最终用户需要对文件（在 .aspx 的情况下）或文件夹（对于 MVC）的权限......尽管这似乎仍然有些隐蔽且不确定。这篇关于应用程序池的文章说它们被用作保护资源的身份，这与需要向最终用户授予权限的想法相矛盾。除非应用程序池和网络服务的规则不同，否则可能会出现这种情况，但会令人惊讶。
