IIS 7アプリケーションプールのIDを正しく設定する方法はありますか。

Question

はIIS7.5への私のウェブサイトを展開した私は1つの奇妙な行動を見つけた：アプリケーションプールIDは、（IIS Application Pool Identitiesに推奨されているように）デフォルトでApplicationPoolIdentityように放置した場合Ninjectは、私は次のエラーを取得するようながら、無視しているようです

のSystem.InvalidOperationException：：非常に最初のコントローラを作成するタイプ のコントローラを作成 にしようとしたときにエラーが発生しました「..MainController」。 に、コントローラにパラメータのないパブリックコンストラクタがあることを確認します。 ---> System.DirectoryServices.DirectoryServicesCOMException：操作 エラーが発生しました。

私は（すべてのサブフォルダとファイルを含む）部位を含む、フォルダにIIS AppPool\<MySiteAppPool>にFullAccessを付与しようとしたが、これは何も変更しませんでした。

ただし、アプリケーションプールIDを任意のドメインアカウント（管理者権限のない単純なものでも、サイトのあるフォルダへのアクセスもなく）に設定すると、正常に動作します。

Ninjectは、Setting up an MVC3 applicationのチュートリアルに従ってNuGetパッケージにインストールされています。

私は確かではありませんが、それは、サイトがWindows認証でドメインイントラネットで動作するはずです。

したがって、唯一の問題はアプリケーションプールのIDと思われます。私が推奨する方法を使用することを熱望している限り、私はドメインアカウントではなくApplicationPoolIdentityを持っていたいと思います。

これは何と接続できますか？これらを一緒に混ぜることは可能ですか？

---

これは、同様の問題：ASP.NET MVC 4 + Ninject MVC 3 = No parameterless constructor defined for this objectのSOスレッドです。しかし、そこには適切な答えもありません。削除されたコメントが示唆したように

---

、私はアイデンティティとしてNetworkSeriveを使用してみました。そしてそれは正しく働いた。しかし、これは特権のないドメインアカウントよりもはるかに良くないと思います。

---

EDIT

は突然、別の依存関係が見つかりました：私は、クライアント側のユーザーの資格情報が使用されることが期待かかわらず、アプリケーションプールIDは、SQL Server上のWindows認証に使用されます。

コメント

に基づいて遠隔のSQLサーバが偽装を介して認証資格情報を使用してアクセスすることができることに同意します。

---

ただし、ApplicationPoolIdentityとNinjectで問題が何であるかはまだ分かりません。

この質問の一番上にある記事では、仮想アカウントにはユーザープロファイルがないという事実が原因と考えられます。この側面は依然として私には不明ですが、IISがLoadUserProfile属性を持つユーザープロファイルを読み込めるようにすることができます。仮想アカウントのプロファイルがない場合、IISがロードされるのは何ですか？

IISはWindowsユーザープロファイルをロードしませんが、特定のアプリケーション は、一時的なデータを保存するために、とにかく、それを活用することがあります

あると言われています。 SQL Express は、これを実行するアプリケーションの例です。ただし、ユーザー プロファイルは、 プロファイルディレクトリまたはレジストリハイブのいずれかに一時データを格納するために作成する必要があります。 NETWORKSERVICEアカウントのユーザープロファイルは、システムによって作成され、常に でした。ただし、固有のアプリケーションプール アイデンティティへの切り替えでは、システムによってユーザープロファイルは作成されません。 標準アプリケーションプール（DefaultAppPoolおよびClassic .NET AppPool） には、ディスク上のユーザープロファイルがあります。 管理者が新しいアプリケーションプールを作成した場合、ユーザープロファイルは作成されません。

ただし、必要に応じて、 "LoadUserProfile"属性を "true"に設定して、ユーザープロファイルを にロードするようにIISアプリケーションプールを構成できます。

---

私はserverfault.com上の次のスレッドが見つかりました：また、クエリ、アプリケーションプールIDは、特に、ネットワークサービスとして動作することができないことが述べられているがあり

How can I assign active directory permission to the default app pool identity

を宣伝。

Answer 1

質問の詳細からは、COMExceptionがスローされて、NinjectがMainControllerをインスタンス化するのを妨げているアクセス権の問題のように思えます。例外は、Active Directoryの照会に使用されるクラスであるSystem.DirectoryServicesに関連しています。

IISが通常のアプリケーションプールアカウントで実行されている場合、これらのアカウントにはActive Directoryに対してクエリを実行する権限がなく、COMExceptionがスローされます。私は例外の実際のメッセージ（パラメータのないコンストラクタを見つけることができません）は、赤ちゃんのビットであり、正常なものが動作しなかったので別のコンストラクタにフォールバックしようとするNinjectだと思います。

これは、IISアプリケーションプールをドメインアカウントとして実行するように変更すると、そのアカウントにドメインを照会する権限があるため、突然動作する理由を説明します。

あなた自身がSystem.DirectoryServicesを使用しているかどうか、またはNinject/IIS/ASPがそれらを使用しているかどうかは疑問からはっきりしません。あなた自身でそれらを使用している場合は、ADクラスのコンストラクタのどれも起動時にクラッシュするのを防ぐ（例外をキャッチしてログに記録する）ことはできません。おそらく、上で私が許可について述べたことを知っているでしょう。

IISを通常のアプリケーションプールアカウントとして実行することをお勧めしますが、それでもドメインユーザーとしてADを照会する場合は、資格情報をDirectoryEntryに指定し、DirectorySearcherを使用してAD検索を実行します。 .Net 4以降であれば、代わりに新しいSystem.DirectoryServices.AccountManagementクラスを使用することをお勧めします（資格情報を指定することもできます）。

この方法では、ADクエリの偽装は不要で、通常のアプリケーションプールアカウントとしても実行できます。

Answer 2

iispool \ appPoolNameアカウントは、仮想アカウント&と呼ばれ、Windows 2008に追加されました。これらのアカウントは、本当の意味でのアカウントではありません。これらが許可するのは、ベースアカウントを使用するプロセス間のセキュリティの強化です。

あなたのマシン上の多くのサービスは、ネットワークアクセスを持つアカウントであるnetworkServiceを使用します。このため、攻撃者がこれらのサービスの1つを悪用すると、同じアカウントで実行されている他のプロセスにアクセスすることができます。 IISで使用されているような仮想アカウントは、これと同じアカウントを使用している間に別のアカウントとして表示されないようにするため、asp.netアプリケーションはまだ技術的にネットワークサービスとして稼動しています&つまり、ネットワークリソースにアクセスする必要がある場合は、networkserviceが&マシンドメインアカウントを使用するため、iispoolアカウントが実行します。

リモートSQLサーバにアクセスする場合は、これを追加してWebサーバからのアクセスを許可する必要があります。 SQLサーバー上のユーザーを本当に知る必要がない限り、偽装の使用はお勧めしません。アプリのセキュリティは、オフにしておくと簡単です。

あなたの注射がうまくいかない理由については、あなたの依存関係が失敗する可能性があります。 controllerAにClassBが注入され、ClassB &が注入され、そのクラスがClassDを注入できなかった場合、チェーン全体が故障する。私はそれが起こった&それは私が見ていたものから削除された何かを実現するためにしばらくかかった。