web-dev-qa-db-ja.com

IIS 7.5基本認証とActive Directory検証

私はIISまたはActive Directoryのエキスパートではないので、ここでシナリオを提示し、達成したいことが実現可能かどうかを確認したいと思います。

IISを通じてAPIとして公開された一連のWebサービスを備えたWindows Server 2008 R2でホストされているアプリケーションがあります。これらのサービスは、複数の外部統合システムによって呼び出されます。 IISサービスが基本認証を使用するように構成すると、IIS Active Directoryに対して渡す資格情報がデフォルトで検証されます。これは特別な構成設定です。 、またはこれは不可能ですか?これらの資格情報をADに対して検証して、代わりにトークン/プリンシパルを受け取り、そのサーバー上の基になるアプリケーションに送信できるようにします。

前もって感謝します。どんな助けでもありがたいです。

4
jturinetti

基本認証は、ADに対する認証で問題なく機能します。IISサーバーのローカルアカウントデータベースに対して認証されます。ドメインメンバーの場合、参加しているフォレスト内のActive Directoryドメインが含まれます。

いかなる種類のkerberosチケットも返されません-基本認証は単にサーバーに送信されたリクエストのヘッダーにパスワードを含め、サーバーはそれを処理します-リクエストされたリソースまたは401エラーを返します。しかし、IIS内のWebアプリケーション内でユーザーIDを探している場合は、その情報(認証されたユーザー/ドメイン)をコードで利用できるはずです。

ブラウザは、セッションの存続期間中、入力されたパスワードをメモリに保持します。そのため、そのサーバーへの後続のリクエストはカバーされますが、他のシステムやサービスへのアクセスはカバーされません。

デフォルトのドメインの構成やユーザーが受け取るプロンプト here など、基本的な認証の構成に関する情報があります。

4
Shane Madden

さて、答えは受け入れられましたが、私は一般的に言うつもりです:

Basicは使用しないでください。

Basic-with-domain-credentialsが正しい答えであると思われる質問がある場合、ほとんどの場合そうではありません。

統合認証を使用します。

Basicを使用すると、悪意のあるWeb開発者がユーザーのAD資格情報を学習し、ゲームオーバーになります。

Integratedを使用すると、ユーザーは自分が本人であることを認証でき、制約付き委任を使用して、Web開発者がトークンで実行できることを制限できます。ユーザー名とパスワードを直接傍受にさらすことはなく(SSLの設定が誤っている(つまり、構成されていない場合)、これは常に発生します)、Webサーバーの共有への書き込みアクセス権を持つユーザーが資格情報を傍受する単純なWebアプリケーションを作成します。

1
TristanK

IISにユーザー資格情報がある場合、それらを使用してそのユーザーのプライマリトークンを作成できます。IISはそのトークンを使用して、そのユーザーになりすましてリソースにアクセスできます他のサーバー上のアプリケーション。

IISマシンとアプリケーションプールID(サービスアカウント)は、トークンを使用してユーザーに代わって動作するために、適切なレベルの偽装または委任用に構成する必要がありますが、このシナリオはIIS/ASP.Netの世界では実際にかなり一般的です。

制約付き委任-Tristanが言及した場合-特定のマシン(制約された部分)上の特定のサービスにアクセスするための完全な委任レベルトークンをユーザーに作成することが実際に可能であり、実際にはパスワードは必要ありません。外部認証メカニズム(スマートカードなど)があり、そのIDのみがWebアプリケーションに渡される場合、これはより安全です。これにより、セキュリティの境界を越えてパスワードを送信する必要がなくなります。

1
Greg Askew

ADを使用してWebユーザーを認証する場合は、統合認証を使用する必要があります。

HTTP基本認証は安全ではなく、保護されておらず、ネットワークトラフィックにアクセスできるすべての人にとって簡単に破られます。

Windowsが基本認証にAD資格情報を使用できるようにすることは、非常に安全ではありません。これにより、これらの資格情報が自動的に信頼できなくなります。

0
adaptr