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

时间：2012-02-04 18:31:55

标签： asp.net security

配置：

  • Windows Server 2008 R2 / IIS 7.5

  • 使用Windows集成身份验证的ASP.NET Web应用程序。应用程序池标识设置为NetworkService。针对.NET Framework 2.0。管理管道模式=经典。

  • 授予Users组和Internet来宾帐户的Temporary ASP.NET Files文件夹的完全权限

  • 作为管理员组成员的测试用户帐户（我们称之为testuser）登录到服务器

  • 用户帐户控制已开启

  • Internet增强安全功能已关闭

  • Internet Explorer正在使用所有默认安全设置，所有兼容性视图设置均已关闭

现在我执行以下操作：

  1. iisreset.exe命令

  2. 清除Temporary ASP.NET Files文件夹

  3. 打开Internet Explorer

  4. 浏览到本地ASP.NET网站=＆gt;成功

  5. 关闭Internet Explorer

  6. iisreset.exe命令

  7. 打开Internet Explorer

  8. 浏览到本地ASP.NET网站=＆gt;的 FAIL

    9. 到目前为止，我发现了一些我可以做的事情来保持网站在iisreset.exe之后工作（每个都是单独工作，即它们不必合并）：

    • 关闭用户帐户控制

    • 以 管理员

      • 身份登录

    • 以“管理员身份...”运行Internet Explorer（而不是默认为testuser帐户）

    • 使用谷歌浏览器或Mozilla Firefox而不是Internet Explorer（？！？）这两个浏览器不必使用管理员帐户运行，但在用户帐户下运行良好，并启用了用户帐户控制

    • 使用在外部计算机上运行的Internet Explorer实例浏览网站

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

    如果用户是Administrators组的成员，则没有区别。

    使用进程监视器，当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的身份验证设置如下：

                                 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似乎是让我的问题消失的另一种方式，但显然还有更多工作要做。

2 个答案:

答案 0 :(得分：2)

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

答案 1 :(得分：0)

我无法想象浏览器与它有任何关系，但如果你遇到差异，那一定是真的。 为了使ASP.NET能够编译ASPX文件，导入了2件事（正如我们今天所发现的那样：

  1. 写入对ASP.NET临时文件dir（编写编译的DLL的位置）的访问权限
  2. 对Windows TEMP（其中csc.exe写入中间文件，如* .obj）
    3. 的写入权限

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

相关问题
最新问题