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.
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().Namenear 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 SERVICEin 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 userIUSR, which was different from the value I’d get in IIS6, which wasNETWORK SERVICE.It seems that in IIS6, NETWORK SERVICE had permission to explore the IIS Metabase through the Active Directory Service Interface (ADSI) with the
DirectoryEntryclass. 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: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.