|統合プロキシ認証: サービス アカウントと偽装

「自分の Windows 資格情報を使う」には主体が必要です。デスクトップ プログラムでは、それを実行している人が主体になる場合があります。サービスでは、サービスのアカウントが主体になる場合があります。Web アプリケーションでは、訪問者のサインイン成功が送信要求のセキュリティ コンテキストを自動的に置き換えるわけではありません。

同じマシン上のブラウザーとサーバー側コードが、統合認証プロキシから異なる結果を受け取ることがあるのはこのためです。両者は別の ID を提示している可能性があります。

コードを変更する前に ID を特定する

• デスクトップ ブラウザーにサインインしている人。
• アプリケーション プロセスをホストしているアカウント。
• 送信操作で有効になっている偽装 ID。
• プロキシが実際に受け入れた、または拒否したアカウント。

.NET がサポートする統合認証の経路では、DefaultCredentials は現在のセキュリティ コンテキストに関係します。別のマシンでページを開いた人のためのグローバルな別名ではありません。

製品が意図的にユーザーとして動作する場合、偽装とネットワーク委任の要件には、それぞれ固有のサポートされた設計が必要です。汎用的な既定の資格情報の使用スイッチをオンにしても、その設計は確立されません。逆に、サービス ID として実行することを意図したバックグラウンド ジョブは、誰かが最初にブラウザーを開くことに依存すべきではありません。

シークレットを除いた状態で、対話的な起動と展開された起動を比較します。アカウントのコンテキスト、プロキシのエンドポイント、通知されたメソッド、拒否された ID です。一度きりの要求が成功したという理由だけで、デスクトップのパスワードをアプリケーションにコピーしないでください。アプリケーションが使用するはずのアカウントを構成し、その所有関係を展開記録に残して見えるようにしてください。