IIS IUSR_Machineアカウントを使用して、アプリケーションプールアカウントを使用する必要があるときにaspnet_isapi.dllをロードするのはなぜですか？
私は最近、IIS 6.0を実行しているWindowsServer 2003サーバーの修正を担当しました：
HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.
Windows Updateパッチ kb263388 が適用された後、これらの応答の提供を開始しました。これにより、IUSR_Machineアカウントと.Netフレームワークディレクトリのデフォルトのアクセス許可が変更されたようです。
問題は、asp.netリソース（.aspxなど）に対するすべての要求が機能しなかったのに、他のすべて（text、htmlなど）が機能したことです。アプリケーションは、IUSR_machineアカウントとアプリケーションプールアカウントのネットワークサービスを使用して匿名要求を処理するように設定されています。
ネットワークサービスアカウントがC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727ディレクトリに正常にアクセスできることを確認しましたが、IUSR_machineアカウントはアクセスできません。 IUSR_machineアカウントにC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727ディレクトリへのアクセスを許可すると、問題は解決します。これは私には非常に奇妙に思えます。
私の質問は、なぜIISアプリケーションプール（ネットワークサービス）のアカウントを使用してaspnet_isapi.dllをロードしないのですか？上記のトラブルシューティングから、実際にを使用していることは明らかです。このためのIUSR_machineは、セキュリティホールのようです。web.configのIDタグも設定されていないため、デフォルトです。
これについて何かアドバイスをいただければ幸いです。
私はあなたの期待に話すことはできませんが、ほとんどすべてのシステムまたは.Net DLLのデフォルトは、ユーザーが読み取りアクセス権を持つことです。
Aspnet_ISAPIはフィルターと拡張機能の両方であるため、W3WPブート（アプリプールアカウントとして）によって、またはスクリプトマップファイルへのアクセスによってロードされる可能性があります（スクリプトマッピングは実際にはDLL in予想どおり、作業を行っているユーザーのコンテキスト）。