DefaultAppPool是否在IIS上带有特殊提升的特权运行？

Question

我正在网页上运行一段代码，该页面使用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上可以正常工作。

任何帮助表示赞赏。

Answer 1

您可能没有意识到，但是运行代码的实际身份可能与进程资源管理器中为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配置数据库 。 但是，IIS7中没有新的IUSR身份。 为了运行上面的代码，您必须直接模拟具有现有ADSI读取权限的帐户 ，例如：

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

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

或者，您应该能够使用MIIS 博客文章中建议的使用IIS7的WMI提供程序来查找所需的信息。

Answer 2

从您的描述中很难确切地知道可能会发生什么，但是据我了解，您有这样的设置：

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

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

foreach (DirectoryEntry de in iisNode.Parent.Children)

仅当默认网站的应用程序池和虚拟目录是相同的物理池时，这才起作用。

Answer 3

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

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

Answer 4

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

您的测试站点中是否有其他身份验证设置？ 例如，如果您已将所选内容集成在一个而不是另一个上……这可能可以解释您遇到的行为。

Answer 5

我将检查以确保NetWorkServices用户有权访问它尝试访问的物理目录。 错误显示您正在访问一个有效站点，而另一个无效站点下的访问其他站点，对吗？

如前一个用户所述，默认的AppPool和您创建的内容没有什么特别的（除非您更改自定义AppPool的设置。IIS会使用任何设置用户的权限在其下运行AppPool。

Answer 6

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

该链接指向存在类似问题的人，他们发现由于Skype在端口80上运行，导致与路径发生冲突。

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