Freigeben über

Why ISAPI Filters can load in some but not all websites on a Domain Controller

  • Artikel

I recently encountered this question from multiple users simultaneously, and while the behavior looks bizarre, the answer is equally peculiar... so I thought it nice to share this little gem...

Question:

Hi All,

I have an isapi filter that works correctly. In one machine the filter load correctly (green arrow) but it seems to be colled only on some virtual directory. There aren't any error in the event viewer. Each Virtual Directory has a different application pool and a different user.

Any suggestion on how to investigate the problem? Unfortunatly I do not have
direct access to the machine but I have the iis logs.

Thank you for any idea.

Answer:

This behavior can be observed on a Domain Controller if the Application Pool Identity is not Network Service or Local Service.

The problem manifests itself because:

  • On a Domain Controller, the IIS_WPG security group is ineffective
  • Metabase ACLs on the /Filters node include Administrators, IIS_WPG, Network Service, and Local Service
  • IIS reads and runs ISAPI Filters using the Application Pool Identity

So, what happens when the Application Pool runs with a customized process identity that is NOT listed in the metabase ACL for the /Filters node? When IIS runs as process identity to read and load ISAPI Filters, it fails to read the Filters node to obtain a list of filters and therefore skips loading filters. Thus, it looks like the exact same filter DLL loads in some application pools (running as Network Service or Local Service) yet fails for other application pools (using IWAM or any other customized identity).

The metabase ACL for /Filters node can be adjusted with a tool like MB Explorer from the IIS Resource Kit Tools.

Normally, Application Pool Identity has to be in the IIS_WPG group and everything works, but on a Domain Controller the IIS_WPG group is ineffective, which breaks all sorts of things. Basically, everywhere you find IIS_WPG on a Domain Controller, you must manually copy and set ACLs for all customized Application Pool Identities. Ick! This is one reason why we do not "support" running IIS6 on a Domain Controller...

Of course, there is also an IIS6 bug in here that has been reported. Anyone want to wager what the bug is?

//David

Comments

  • Anonymous
    June 08, 2008
    Would the IIS 6.0 bug be that the ACL on the filters node of an individual site entry in the metabase doesn't always have IIS_WPG group assigned to it? I just spent the better part of a week tracking down this gem. We don't generally run app pools as NETWORK SERVICE, preferring instead to use a domain account that's part of the individual machine IIS_WPG. We migrated a site that uses an ISAPI filter from one Windows 2003 server to a new one.  The original was a Windows 2003 Web Edition  RTM that has been upgraded over time to SP2.  The new machine is Windows 2003 R2 Server w/ SP2 slipstreamed. I'm not sure if that was the difference, but the first machine had the permissions correctly set without using metaacl.

  • Anonymous
    June 10, 2008
    Eric - the problem is that IIS relies on IIS_WPG to propagate permissions everywhere , so when you are in an environment (like Datacenter) or manually create your own metabase nodes which do not use IIS_WPG, behavior will be confusing and hard to maintain. Everywhere where there used to be IIS_WPG ACL will need to be re-ACL'd for every possible Application Pool Identity, including the new one that you'll add two years from now when you've forgotten where you need to re-ACL. //David