DefaultAppPool 是否在 IIS 上以特殊提升的权限运行？答案

【问题标题】：Does DefaultAppPool run with special elevated privilegs on IIS?DefaultAppPool 是否在 IIS 上以特殊提升的权限运行？
【发布时间】：2010-11-01 19:53:02
【问题描述】：

我正在使用 ADSI 查询 IIS 元数据库的网页中运行一段代码。代码就这么简单：

        DirectoryEntry iisNode = 
        new DirectoryEntry("/LM/W3SVC/1/ROOT/MyAspWebsite-1-128886021498831845");
        foreach (DirectoryEntry de in iisNode.Parent.Children)
        {
            System.Console.WriteLine(de.Name);
        }

当我在 IIS7/W2K8 上的 DefaultAppPool 下运行页面/站点时，这可以正常工作。但是，当我创建自己的应用程序池并使属性与默认应用程序池相同时，此代码将失败并出现以下错误：

Caught: System.Runtime.InteropServices.COMException
Failed to parse virtual directory: 
      /LM/W3SVC/1/ROOT/MyAspWebsite-1-128889542757187500
System.Runtime.InteropServices.COMException (0x80070005): Access is denied.

DefaultAppPool 有哪些特权？我没有看到任何记录。我需要它在非默认应用程序池中工作，但没有为整个工作进程提供提升的权限。我还尝试使用 DirectoryEntry 构造函数的用户名和密码参数，在运行 IIS7 的机器上使用 Admin，但这并没有改变任何东西。我还要注意，这在 IIS6 和 W2K3 上很好工作。

感谢任何帮助。

【问题讨论】：

您确定两个应用程序池都在同一个身份下运行吗？
是的，如果您查看进程资源管理器，它们都作为 NT AUTHORITY\NETWORK SERVICE 运行，并且都具有“系统”的完整性。如果您查看 w3wp.exe 两个实例的高级属性的进程资源管理器下的安全选项卡，它们属于完全相同的一组组，只有一个区别，DefaultAppPool 是 IIS APPPOOL\DefaultAppPool 组的一部分，并且自定义应用程序池属于 IIS APPPOOL\CustomAppPool 组。
当您说您创建了自己的应用程序池时，您是否只是创建了一个全新的应用程序池并将您现有的应用程序添加到其中并且它失败了？或者，您是否正在创建一个与新应用程序池相关联的全新站点（因此，可能是根上的应用程序）？也许权限问题是因为您在路径 /LM/W3SVC/1/ROOT... 中引用了站点 ID 1...？
我怀疑一年后你仍然需要一个答案，但我遇到了和你一样的问题，花了一整天的时间来摸索。我希望我下面的回答有一天能帮助别人。 stackoverflow.com/questions/975838/…

标签： asp.net iis iis-7 active-directory iis-6

【解决方案1】：

我会检查您访问目录条目的路径。您可能有一些冲突的服务。检查您的事件查看器。

此链接发给遇到类似问题并发现because Skype was running on port 80 it was causing a conflict with the path.的人

但您问题的真正答案是“不，默认应用程序池没有什么特别之处”。

【讨论】：

我访问目录条目的路径是什么意思？路径是 IIS 元数据库。端口与此有什么关系？据我了解，IIS7 中的元数据库存储在 XML 文件中。
我输入的链接表明在端口 80 上有其他内容可能会增加路径中的 /1/

【解决方案2】：

我会检查以确保 NetWorkServices 用户有权访问它尝试访问的物理目录。错误显示您正在访问不同的网站，一个有效，一个无效，对吗？

正如前一位用户所说，默认 AppPool 和您创建的 AppPool 没有什么特别之处（除非您更改自定义 AppPool 的设置。IIS 确实使用设置的任何用户的权限来运行 AppPool。

【讨论】：

【解决方案3】：

从您的描述中很难准确判断可能发生的情况，但据我了解，您有这样的设置：

DefaultWebSite
  |
  +-- VirtualDirectory
        |
        +-- ShowIISMetaData.aspx

我认为问题在于应该显示 IIS 元数据的页面正试图查看其父级的子级（即其兄弟姐妹）。

foreach (DirectoryEntry de in iisNode.Parent.Children)

这仅在默认网站的应用程序池和虚拟目录相同时才有效物理池。

【讨论】：

【解决方案4】：

此问题缺少一些信息。两个帐户都在同一个用户帐户下运行，因此行为应该相同。我建议您尝试在 IIS 的 vanilla 安装下运行代码，问题仍然存在吗？

正如其他人所暗示的，如果帐户相同，那是因为您对元数据库进行了一些修改。

【讨论】：

【解决方案5】：

与应用程序池关联的凭据将是尝试查询 AD 时使用的凭据。因此，如果两个应用程序池都在相同的凭据下运行，那不是您的问题。

您的测试站点中是否有不同的身份验证设置？例如，如果您在一个而不是另一个上集成了选择...这可以解释您遇到的行为。

【讨论】：

【解决方案6】：

您可能没有意识到，但运行代码的实际身份可能与进程资源管理器中为 w3wp.exe 列出的身份不同。您应该设置断点或在引发 COMException /“访问被拒绝”冲突的违规代码行 (DirectoryEntry.Parent.Children) 附近运行 WindowsIdentity.GetCurrent().Name。

例如，对我来说，我的应用程序池进程 w3wp.exe 在任务管理器窗口中以NETWORK SERVICE 的身份运行，正如您在上面描述的那样。但是，当我检查实际运行时标识时，发现它是新的 IIS7 内置用户 IUSR，这与我在 IIS6 中获得的值不同，即 NETWORK SERVICE。

using System.Security.Principal;

Console.WriteLine(
    WindowsIdentity.GetCurrent().Name); // IUSR on IIS7, NETWORKSERVICE on IIS6
foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children))
{
    System.Console.WriteLine(de.Name);
}

似乎在 IIS6 中，NETWORK SERVICE 有权通过带有 DirectoryEntry 类的 Active Directory 服务接口 (ADSI) 探索 IIS Metabase。但是，IIS7 中的新 IUSR 标识没有。为了运行上述代码，您必须直接impersonate an account 使用现有的 ADSI 读取权限，例如：

using (new MyImpersonationWrapper("admin","pass"))
{
    foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children))
    {
        System.Console.WriteLine(de.Name);
    }
}

实施您自己的模拟包装器并保护适当的本地帐户是我将留给您的练习，因为您的（安全）需求可能会有所不同。

或者，您应该能够使用WMI provider for IIS7 来查找所需的信息，而不是suggested on this MSDN blog post。

【讨论】：