Does DefaultAppPool run with special elevated privilegs on IIS?

Question

I'm running a piece of code within a web page that queries the IIS metabase using ADSI. The code is as simple as this:

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

This works fine when I run the page/site under the DefaultAppPool on IIS7/W2K8. However when I create my own app pool and leave the properties the same as the default app pool, this code fails with the following error:

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.

What special privileges does the DefaultAppPool have? I don't see any documented. I need this to work in non default app pools, but without giving the entire worker process elevated privileges. I've also tried using the username and password parameters of the DirectoryEntry constructor, by using the Admin on the machine that IIS7 is running on, but that didn't change anything. I'll also note that this works fine on IIS6 and W2K3.

Any help is appreciated.

Answer 1

I would check the path that you are accessing the directory entry on. Its possible that you may have some conflicting service. Check your event viewer.

This link goes to someone who had a similar problem and found that because Skype was running on port 80 it was causing a conflict with the path.

But the real answer to your question is "No, there isn't anything special about the default app pool".

Answer 2

I would check to make sure that the NetWorkServices user has access to the physical directories that it is trying to access. It appears by the error that you are accessing different sites under the one that works and one that does not, is that correct?

As stated by the previous user there is nothing special about the Default AppPool and one you create (unless you change the settings of the custom AppPool. IIS does use the permissions of whatever user is setup to run the AppPool under.

Answer 3

It is a little hard to tell from your description exactly what might be going on but from what I understand you have a setup like this:

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

I think the problem is that the page that is supposed to show the IIS MetaData is attempting to look at the children of its parent (in other words its siblings).

foreach (DirectoryEntry de in iisNode.Parent.Children)

This will only work if the application pool for the default website and the virtual directory are the same physical pool.

Answer 4

There is some information missing from this issue. Both accounts are running under the same user account so the behaviour should be the same. I suggest you try running the code under a vanilla install of IIS, does the problem still occur?

As others have alluded to, if the accounts are the same, its because you have made some modification of the metabase.

Answer 5

The credentials associated with the app pool will be the one used when attempting to query AD. So if both App pools are running under the same credentials that is not your problem.

Do you have different authentication setting in place in your test sites? If for example, you have integrated selected on one and not another ... that may explain the behavior you're experiencing.

Answer 6

You might not realize it, but the actual identity running your code may not be the same as the one listed for w3wp.exe in process explorer. You should set a breakpoint or run WindowsIdentity.GetCurrent().Name near the offending line of code (DirectoryEntry.Parent.Children) that throws the COMException / "Access denied" violation.

For example, for me, my App Pool process, w3wp.exe, was running as NETWORK SERVICE in the task manager window, as you described above as well. However, when I checked the actual runtime identity, it turned out it was the new IIS7 built-in user IUSR, which was different from the value I'd get in IIS6, which was 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);
}

It seems that in IIS6, NETWORK SERVICE had permission to explore the IIS Metabase through the Active Directory Service Interface (ADSI) with the DirectoryEntry class. The new IUSR identity in IIS7, however, does not. In order to run the above code, you'll have to directly impersonate an account with existing ADSI read privileges, for example:

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

Implementing your own impersonation wrapper and securing a proper local account is an exercise I'll leave to you, as your (security) needs may vary.

Alternatively, you should be able to look up your desired information using the WMI provider for IIS7 instead, as suggested on this MSDN blog post.