IIS 7アプリケーションプールIDを正しく設定する方法は？
WebサイトをIIS7.5に展開したところ、奇妙な動作が1つ見つかりました。アプリケーションプールIDがデフォルトでApplicationPoolIdentityのままになっている場合（ IISアプリケーションプールID で推奨）、Ninjectは、最初のコントローラーの作成中に次のエラーが発生するため、無視されるようです。
System.InvalidOperationException：タイプ '..MainController'のコントローラーを作成しようとしたときにエラーが発生しました。コントローラーにパラメーターのないパブリックコンストラクターがあることを確認します。 ---> System.DirectoryServices.DirectoryServicesCOMException：操作エラーが発生しました。
サイト（すべてのサブフォルダーとファイルを含む）を含むフォルダーにFullAccessをIIS AppPool\<MySiteAppPool>に付与しようとしましたが、何も変更されませんでした。
ただし、アプリケーションプールIDを任意のドメインアカウントに設定すると（単純なものでも、管理者特権がなく、サイトのあるフォルダーへのアクセス権もありません）、正常に機能します。
Ninjectは、NuGetパッケージを通じて MVC3アプリケーションのセットアップ チュートリアルに従ってインストールされます。
関連性がある場合、サイトはWindows認証を使用するドメインイントラネットで動作するはずです。
したがって、唯一の問題は、アプリケーションプールIDにあるようです。私が推奨される方法を使いたいと思っている限り、ドメインアカウントではなくApplicationPoolIdentityが欲しいです。
これは何と関係がありますか？これらすべてを一緒に混ぜることは可能ですか？
SO同様の問題のあるスレッド： ASP.NET MVC 4 + Ninject MVC 3 =このオブジェクトにはパラメーターのないコンストラクターが定義されていません 。ただし、適切な回答はありませんすべてのいずれか。
削除されたコメントが示唆したように、私はNetworkSeriveをIDとして使用してみました。そして、それは適切に機能しました。ただし、これは非特権ドメインアカウントよりもはるかに優れているとは思いません。
[〜＃〜]編集[〜＃〜]
突然別の依存関係が見つかりました：アプリケーションサーバーのIDがSQLサーバーのWindows認証に使用されていますが、クライアント側のユーザーの資格情報がそこで使用されることを期待していました。
コメントに基づいて
認証された資格情報を使用して、偽装を介してリモートSQLサーバーにアクセスできることに同意します。
ただし、ApplicationPoolIdentityとNinjectの問題はまだ明確ではありません。
この質問の冒頭で述べた記事は、仮想アカウントにユーザープロファイルがないという事実が原因である可能性があると思いました。 IISを有効にしてLoadUserProfile属性を持つユーザープロファイルをロードすることができるため、この側面は不明確なままです。取得できません。IIS仮想アカウントのプロファイルがない場合、ロードしますか？
それはそこで言われています：
IISはWindowsユーザープロファイルをロードしませんが、特定のアプリケーションはとにかくそれを利用して一時データを保存する場合があります。 SQL Expressは、これを行うアプリケーションの例です。ただし、一時データをプロファイルディレクトリまたはレジストリハイブに保存するには、ユーザープロファイルを作成する必要があります。 NETWORKSERVICEアカウントのユーザープロファイルはシステムによって作成され、常に使用可能でした。ただし、一意のアプリケーションプールIDへの切り替えにより、ユーザープロファイルはシステムによって作成されません。標準のアプリケーションプール（DefaultAppPoolおよびClassic .NET AppPool）のみがディスク上にユーザープロファイルを持っています。管理者が新しいアプリケーションプールを作成しても、ユーザープロファイルは作成されません。
ただし、必要に応じて、「LoadUserProfile」属性を「true」に設定することで、ユーザープロファイルをロードするようにIISアプリケーションプールを構成できます。
Serverfault.comで次のスレッドを見つけました。
Active Directoryのアクセス許可を既定のアプリプールIDに割り当てる方法
また、アプリプールIDがネットワークサービスとして機能できず、特にADにクエリを実行できないとも述べられています。
質問の詳細から見ると、COMExceptionがスローされる原因となる権限の問題によく似ており、NinjectがMainControllerをインスタンス化できなくなります。例外は、Active Directoryのクエリに使用されるクラスであるSystem.DirectoryServicesに関連しています。
IISが通常のアプリプールアカウントで実行されている場合、それらのアカウントにはActive Directoryに対してクエリを実行する権限がなく、COMExceptionがスローされる可能性があります。実際のメッセージは例外では（パラメーターのないコンストラクターを見つけることができません）は少しニシンであり、Ninjectは通常のコンストラクターが機能しなかったため、別のコンストラクターにフォールバックしようとしています。
IISアプリプールをドメインアカウントとして実行するように変更すると、そのアカウントにはドメインをクエリする権限があるため、突然機能する理由がわかります。
あなたがSystem.DirectoryServicesを自分で使用しているかどうか、またはNinject/IIS/ASPがそれらを使用しているかどうかという質問からは明確ではありません。ただし、自分で使用している場合は、ADクラスのコンストラクターが例外をスロー（キャッチしてログに記録するなど）できないことを確認してください。これにより、アプリが起動時にクラッシュするのを防ぎます。おそらく、パーミッションについて上記で私が言ったことがわかるでしょう。
IISを通常のアプリプールアカウントとして実行することをお勧めしますが（これは良いアイデアです）、ADをドメインユーザーとしてクエリする場合は、資格情報を DirectoryEntry およびDirectorySearcherを使用してAD検索を実行します。Net4以降を使用している場合は、新しい System.DirectoryServices.AccountManagement を使用することをお勧めします=代わりにクラス（資格情報を指定することもできます）。
その方法では、ADクエリの偽装は必要なく、アプリプールは通常のアプリプールアカウントとして実行できます。
iispool\appPoolNameアカウントは仮想アカウントと呼ばれ、Windows 2008に追加されました。これらのアカウントは、本当の意味では実際にはアカウントではないという考え方です。彼らが許可するのは、基本アカウントを使用するプロセス間の強化されたセキュリティです。
マシン上の多くのサービスは、ネットワークアクセスを備えたビルトインアカウントであるnetworkServiceを使用します。このため、攻撃者がこれらのサービスのいずれかを利用した場合、同じアカウントで実行されている他のプロセスにアクセスできます。 IISで使用されているものなどの仮想アカウントは、同じアカウントでありながら、別のアカウントとして表示されることでこれを防ぎます。asp.netアプリは、技術的にはネットワークサービスとして実行されており、このアカウントにアクセスを許可していますつまり、ネットワークリソースにアクセスする必要がある場合、iispoolアカウントはnetworkserviceがマシンドメインアカウントを使用するのと同じように機能します。
リモートSQLサーバーにアクセスしている場合、これは、Webサーバーからのアクセスを許可するために追加する必要があるアカウントです。 SQLサーバー上でユーザーが誰であるかを本当に確認する必要がない限り、偽装の使用はお勧めしません。アプリのセキュリティをオフにすると、より簡単になります。
インジェクションが機能しない理由については、依存関係のいずれかが失敗している可能性があります。 controllerAにClassBが注入され、次にClassCが注入され、そのクラスがClassDの注入に失敗すると、チェーン全体が失敗します。私はそれを経験しました、そしてそれが私が見ていたものからあまりにも離れたものであることを理解するのにしばらく時間がかかりました。