使用服务器自己的 Internet Explorer 浏览站点时，在 iisreset 后拒绝访问 Temporary ASP.NET Files 文件夹答案

【问题标题】：Access denied to Temporary ASP.NET Files folder after iisreset when browsing site using the server's own Internet Explorer使用服务器自己的 Internet Explorer 浏览站点时，在 iisreset 后拒绝访问 Temporary ASP.NET Files 文件夹
【发布时间】：2012-02-26 22:29:05
【问题描述】：

配置：

Windows Server 2008 R2/IIS 7.5
使用 Windows 集成身份验证的 ASP.NET Web 应用程序。应用程序池标识设置为 NetworkService。面向 .NET Framework 2.0。托管管道模式 = 经典。
授予用户组和 Internet 访客帐户的 Temporary ASP.NET Files 文件夹的完全权限
作为管理员组成员的测试用户帐户（我们称之为 testuser）登录服务器
用户帐户控制已开启
Internet 增强安全性已关闭
Internet Explorer 正在使用所有默认安全设置，并且所有兼容性视图设置均已关闭

现在我执行以下操作：

iisreset.exe
清除 ASP.NET 临时文件夹
打开 Internet Explorer
浏览到本地 ASP.NET 网站 => 成功
关闭 Internet Explorer
iisreset.exe
打开 Internet Explorer
浏览到本地 ASP.NET 网站 => FAIL

到目前为止，我已经找到了一些可以在 iisreset.exe 之后保持网站正常运行的方法（每个都可以单独工作，即它们不必组合在一起）：

关闭用户帐户控制
以管理员身份登录
以“管理员身份...”运行 Internet Explorer（而不是默认使用 testuser 帐户）
使用 Google Chrome 或 Mozilla Firefox 代替 Internet Explorer(?!?) 这两个浏览器不必使用管理员帐户运行，但在用户帐户下运行并在用户帐户控制打开的情况下运行良好.
使用在外部计算机上运行的 Internet Explorer 实例浏览网站

此问题在 Windows Server 2003 上不存在。它似乎与用户帐户控制有关。

用户是否是管理员组的成员没有区别。

使用进程监视器，当 NetworkService (w3wp.exe) 模拟用户时，似乎会发生访问被拒绝问题，但考虑到授予 Temporary ASP.NET Files 文件夹的所有权限，这仍然没有多大意义.

问题是：

为什么这只发生在本地 Internet Explorer 浏览器中，以非管理员用户身份运行？我想使用本地 Internet Explorer 浏览器进行测试，但是在 iisreset 后必须清除 Temporary ASP.NET Files 文件夹很烦人。

在这种情况下，Internet Explorer 与 Chrome 或 Firefox（两者都有效）有何不同？我可以理解这是否会影响所有本地浏览器，但事实并非如此。

当检测到 Internet Explorer 被用作客户端浏览器时，我可以理解我的 Web 应用程序是否正在做一些特殊的事情，但我不认为是这种情况，我们在这里谈论的是程序集绑定失败 - 我是不试图访问一些任意文件夹。

编辑：

以上测试是使用 Internet Explorer 8 完成的。此后我在同一台机器上尝试了 Internet Explorer 9，但结果相同。
如果我为网站启用 ASP.NET 模拟，问题就会消失 - 但我仍然想知道为什么在禁用 ASP.NET 模拟时它对本地 Internet Explorer 不起作用。

编辑 2：

我第一次没有提到的是登录是一个两步过程：当访问应用程序（我们称之为“MyWebApp”）时，您将被重定向到 MyWebApp/Login 目录，您将在该目录中收到提示在授予对位于该登录目录中的登录页面的访问权限之前获取您的 Windows 凭据。

这总是有效的。

输入您的应用程序凭据后（如果登录页面中的代码无法识别您的 Windows 凭据），您将被重定向到根文件夹中的页面。

MyWebApp 和 MyWebApp/Login 的 Authentication 设置如下：

                             MyWebApp         MyWebApp/Login
                             --------         --------------
Anonymous Authentication     Enabled          Disabled
ASP.NET Impersonation        Disabled         Enabled
Basic Authentication         Disabled         Disabled
Digest Authentication        Disabled         Disabled
Forms Authentication         Enabled          Enabled
Windows Authentication       Enabled          Enabled

在这两种情况下，我都会收到“不能同时使用基于挑战和基于登录重定向的身份验证”的警告。

这些设置可以追溯到我参与该项目之前，但这不是重点。现在我只对如何正确处理它感兴趣 - 最好是一组适用于 IIS 6.0 和 7.x 的设置。

为“MyWebApp/Login”设置 ASP.NET Impersonation = Disabled 似乎是解决我的问题的另一种方法，但显然还有更多工作要做。

【问题讨论】：

出于兴趣，是否启用了 Internet Explorer 的集成 Windows 身份验证？转到工具 -> 高级并向下滚动列表。如果是，请禁用它，然后重试 - 这有什么不同吗？
该设置默认启用。禁用它（是的，我确实记得重新启动 IE）没有任何区别。
我想知道属于运行 IE 的用户的权限是否存在某种冲突。您可以随时尝试使用 Process Monitor 运行并查看 www 服务的不同之处！
我已经尝试了提供的建议，使 IE 像 Firefox 一样，而 Firefox 像 IE 一样，但没有任何区别（或者我没有正确重新配置浏览器）。我已经找到并添加了更多信息，这些信息表明问题是由于我的 IIS 目录设置造成的，尽管这仍然不能解释浏览器的差异，但在我花更多时间让浏览器访问之前，我最好先搞清楚这些采取同样的行动。
这可能对stackoverflow.com/questions/17631211/…有帮助

标签： asp.net security

【解决方案1】：

这个问题几乎可以肯定与 Internet Explorer 使用 Windows authentication 而不是 Basic Authentication（你可能会使用 FF 或 Chrome）有关。 Windows 身份验证和ASP.NET impersonation 的组合。如果您enable NTLM authentication in Firefox，您可能会在那里看到相同的行为。同样，禁用 Windows 身份验证（强制 IE 使用基本身份验证）或禁用模拟可能会导致 IE 的行为类似于 Firefox。

【讨论】：

我无法让浏览器表现得像彼此一样，但我确实发现我的 IIS 目录设置可能不正确。我添加了有关我的配置的更多信息。

【解决方案2】：

我无法想象浏览器与它有什么关系，但如果你经历过差异，那一定是真的。为了让 ASP.NET 能够编译 ASPX 文件，需要导入 2 个东西（正如我们今天发现的那样：

对 ASP.NET 临时文件目录（写入已编译的 DLL）的写入权限
对 Windows TEMP 的写入权限（csc.exe 在其中写入 *.obj 等中间文件）

哪个用户应该有访问权限？要看。在我们的例子中是应用程序池用户。在您的情况下，可能是模拟用户。或IUSR。对我来说，那部分仍然是模糊的。

【讨论】：