9

Web サイトを IIS7.5 にデプロイしたところ、奇妙な動作が 1 つ見つかりました。アプリケーション プール ID をApplicationPoolIdentityデフォルトのままにしておくと ( IIS Application Pool Identitiesで推奨されているように)、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 = No parameterless constructor defined for this object . しかし、そこにも適切な答えはまったくありません。

削除されたコメントが示唆したように、私NetworkSeriveはアイデンティティとして使用してみました。そして、それは適切に機能しました。ただし、これは特権のないドメイン アカウントよりも優れているとは言えません。

編集

突然、別の依存関係が見つかりました。クライアント側のユーザーの資格情報がそこで使用されることを期待していましたが、アプリケーション プール ID は SQL サーバーでの Windows 認証に使用されます。

コメントに基づく

偽装を介して、認証された資格情報を使用してリモート SQL サーバーにアクセスできることに同意します。

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

この質問の一番上にある記事から、仮想アカウントにユーザー プロファイルがないことが原因である可能性があると推測されました。LoadUserProfileIIS が属性を使用してユーザー プロファイルをロードできるようにすることができるため、この側面は私には不明なままです。仮想アカウントのプロファイルがない場合、IIS は何をロードするのかわかりません。

そこでは次のように言われています。

IIS は Windows ユーザー プロファイルをロードしませんが、特定のアプリケーションはそれを利用して一時データを保存する場合があります。SQL Express は、これを行うアプリケーションの例です。ただし、一時データをプロファイル ディレクトリまたはレジストリ ハイブに格納するには、ユーザー プロファイルを作成する必要があります。NETWORKSERVICE アカウントのユーザー プロファイルはシステムによって作成され、常に使用可能でした。ただし、一意のアプリケーション プール ID に切り替えると、システムによってユーザー プロファイルが作成されなくなります。標準のアプリケーション プール (DefaultAppPool および Classic .NET AppPool) のみがディスク上にユーザー プロファイルを持ちます。管理者が新しいアプリケーション プールを作成した場合、ユーザー プロファイルは作成されません。

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

serverfault.com で次のスレッドを見つけました。

Active Directory のアクセス許可を既定のアプリ プール ID に割り当てるにはどうすればよいですか?

そこには、アプリケーション プール ID がネットワーク サービスとして機能できないこと、特に AD にクエリを実行できないことが記載されています。

4

2 に答える 2

9

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

マシン上の多くのサービスは、ネットワーク アクセスを持つ組み込みアカウントである networkService を使用します。このため、攻撃者がこれらのサービスの 1 つを悪用した場合、同じアカウントで実行されている他のプロセスにアクセスできます。IIS で使用されるような仮想アカウントは、同じアカウントでありながら、別のアカウントとして表示されることでこれを防ぎます。これはまた、ネットワーク リソースにアクセスする必要がある場合、ネットワーク サービスがマシン ドメイン アカウントを使用するように、iispool アカウントがアクセスすることを意味します。

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

インジェクションが機能しない理由については、依存関係のいずれかが失敗している可能性があります。controllerA に ClassB が注入され、次に ClassC が注入され、そのクラスが ClassD の注入に失敗した場合、チェーン全体が失敗します。私はそれが起こったことがあり、それが私が見ているものから非常に離れたものであることに気付くのにしばらく時間がかかりました.

于 2013-04-06T00:04:37.143 に答える
2

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

IIS が通常のアプリ プール アカウントで実行されている場合、それらのアカウントには Active Directory に対してクエリを実行する権限がなく、COMExceptionスローされる可能性があります。例外の実際のメッセージ (パラメーターなしのコンストラクターが見つかりません) はちょっとしたニシンであり、通常のコンストラクターが機能しなかったため、Ninject が別のコンストラクターにフォールバックしようとしていると思います。

IIS アプリ プールをドメイン アカウントとして実行するように変更すると、突然動作する理由が説明できます。なぜなら、そのアカウントにはドメインをクエリする権限があるからです。

System.DirectoryServices自分で使っているのか、Ninject/IIS/ASPが使っているのか、質問からはわかりません。ただし、自分でそれらを使用している場合は、AD クラスのコンストラクターが例外をスロー (キャッチしてログに記録するなど) できないことを確認してください。これにより、起動時にアプリがクラッシュするのを防ぐことができます。おそらく、パーミッションについて上で述べたことがわかります。

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

この方法では、AD クエリの偽装は必要なく、アプリ プールは引き続き通常のアプリ プール アカウントとして実行できます。

于 2013-04-05T15:13:30.693 に答える