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

  • Article

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