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上运行 fine 。

感谢任何帮助。

Answer 1

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

例如，对我来说，我的应用程序池进程w3wp.exe在任务管理器窗口中作为NETWORK SERVICE运行，如上所述。但是，当我检查实际的运行时标识时，结果是新的IIS7内置用户IUSR，这与我在IIS6中获得的值NETWORK SERVICE不同。 / p>

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服务接口（IIS Metabase）探索ADSI。但是，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。

Answer 2

从您的描述中确切地说出可能发生的事情有点难以理解，但据我所知，您有这样的设置：

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

我认为问题是应该显示IIS MetaData的页面正在尝试看看它的父母的孩子（换句话说是它的兄弟姐妹）。

foreach (DirectoryEntry de in iisNode.Parent.Children)

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

Answer 3

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

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

Answer 4

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

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

Answer 5

我会检查您正在访问目录条目的路径。您可能会遇到一些有冲突的服务。检查您的活动查看器。

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

的人

但问题的真正答案是“不，默认应用程序池没有任何特殊之处”。

Answer 6

我会检查以确保NetWorkServices用户可以访问它尝试访问的物理目录。错误似乎是您正在访问不起作用的网站，而不是正确的网站，这是正确的吗？

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

DefaultAppPool是否在IIS上使用特殊的提升权限运行？

6 个答案: