プロキシサーバーと WinRM

Windows リモート管理 (WinRM) は、HTTP と HTTPS を使用して、クライアントコンピューターとサーバーコンピューター間でメッセージを送信します。 一般に、WinRM クライアントはメッセージを直接 WinRM サーバーに送信します。 WinRM クライアントは、プロキシサーバーを使用するように構成することもできます。

詳細については、以下のセクションを参照してください。

WinRM 2.0 用のプロキシサーバーの構成

WinRM 2.0 では、幅広いプロキシ構成がサポートされています。 たとえば、WinRM では、HTTP および HTTPS トランスポートのプロキシと、認証および認証されていないプロキシサーバーをサポートしています。

プロキシ接続の HTTPS-Based

セキュリティと接続ベースのアフィニティを向上させるには、トランスポートメカニズムとして HTTPS を使用する必要があります。

プロキシサーバーが認証を必要とする場合、WinRM クライアントとサーバーは HTTPS を使用する必要があります。

注意

プロキシサーバーへの認証は、認証から移行先サーバーへの独立しています。

 

プロキシ接続の HTTP-Based

プロキシサーバー認証が必要ない場合は、HTTP または HTTPs のいずれかをトランスポートに使用できます。 ただし、プロキシサーバー経由で WinRM クライアントから WinRM サーバーへの HTTP ベースの接続に問題が発生する可能性があります。

HTTP ベースの接続を使用しているときに、次の問題が発生する可能性があります。

  • プロキシサーバーは、接続ベースの認証をサポートしていません。これにより、移行先サーバーに対する認証がアクセス拒否エラーで失敗する可能性があります。
  • 移行先サーバーとプロキシサーバーに接続するには、複数の資格情報のセットが必要です。
  • HTTP ベースのプロキシサーバーでは、関連付けられたクライアントベースおよびサーバーベースの接続を維持する機能がサポートされていない場合があります。 プロキシがクライアントをサーバーに厳密にリンクしておらず、TCP/IP 接続を維持していない場合は、認証されていないクライアントがデータにアクセスできる可能性があります。 また、接続アフィニティがないと、サーバーに対する認証が失敗する可能性があります。

HTTP をトランスポートとして使用する必要がある場合は、より優れた WinRM 応答を実現し、WinRM クライアントのアクセス拒否エラーを防ぐために、プロキシサーバーで次の構成をサポートする必要があります。

  • HTTP/1.1 のサポート。 HTTP/1.1 は、クライアントとサーバー間の接続関係のマッピングにおいてより厳格です。

  • ネゴシエート、Kerberos、CredSSP 認証の接続ベースの認証。

    要求を認証するには、クライアントとサーバーの間に複数のラウンドトリップが必要です。 認証 (WinRM) サーバーが401応答 (承認されていません) ではない応答をクライアントに送信すると、認証のほとんどのネゴシエーションが完了します。 401応答ではないクライアントに対して WinRM サーバーから応答が返された場合、プロキシは接続を閉じることができません。

    実際のパケットデータが送信される前に、クライアントとサーバーの間で複数の要求/応答ペアを送信できます。 WinRM 2.0 では、ネゴシエートと Kerberos 認証スキームを使用して、余分なラウンドトリップを追加することができます。 認証が完了するまで、データをサーバーに送信することはできません。

    WinRM サーバーは、認証が完了したことを示す200レベルの応答を返します。 HTTP ベースのプロキシサーバーは、接続ベースの認証アフィニティを終了し、WinRM サーバーから200レベルの応答を受信した後に TCP/IP 接続を閉じることができます。 クライアントからサーバーへの最後のラウンドトリップには、元の要求パケットは含まれません。 プロキシサーバーが接続を閉じた場合、サーバーはクライアントの再認証を試行します。クライアント要求がサーバーに送信されることはありません。 接続ベースのアフィニティが維持されていない場合は、移行先サーバーに対する認証がアクセス拒否エラーで失敗することがあります。

  • 接続の永続性。 プロキシへのクライアント TCP/IP 接続は、プロキシからサーバーへの同じ TCP/IP 接続に引き続きマップする必要があります。 この接続を維持することで、より高いレベルのパフォーマンスを実現できます。 接続が維持されていない場合は、すべての要求が再認証される必要があり、パフォーマンスに影響する可能性があります。

暗号化と WinRM 2.0

WinRM 2.0 では、Negotiate、Kerberos、および CredSSP 認証スキームを使用した HTTP 経由の暗号化がサポートされています。 WinRM サーバーが HTTP をサポートし、プロキシ経由でアクセスする場合、WinRM サーバーは暗号化を強制し、暗号化されていないネットワークトラフィックを許可しないようにする必要があります。

どのような状況でも、暗号化されていない HTTP 要求はプロキシサーバー経由で送信されます。 データが移行先サーバーに送信される前にプロキシサーバーを通過する必要がある場合、次のようなセキュリティの問題が非常に重要になります。

  • 悪意のあるプロキシサーバーが、資格情報を含むすべての要求/応答のペアを調べる可能性があります。
  • TCP/IP 接続が WinRM クライアントとプロキシサーバーの両方とプロキシサーバーと移行先サーバーの間で厳密にマップされていない場合、認証されていないクライアントは、プロキシサーバーから移行先サーバーへの同じ認証された接続を使用して、移行先サーバーに接続できます。 移行先サーバーでは、認証されていないクライアントがデータにアクセスできる可能性があります。 暗号化が適用されている場合、移行先サーバーは、認証されていないクライアントにアクセス拒否メッセージを送信します。

暗号化を使用すると、このような潜在的なセキュリティの問題を軽減できます。

WinRM 1.1 以前のプロキシサーバーの構成

WinRM サーバーに接続するためにプロキシが必要な場合、WinRM クライアントは Windows HTTP サービス (WinHTTP) プロキシの構成に依存します。 既定では、WinHTTP はプロキシサーバーを使用するように構成されていません。 WinHTTP プロキシの構成は、 ProxyCfg.exe または netsh コマンドラインユーティリティを使用して変更できます。

WinRM 1.1 以前: WinRM は Internet Explorer のプロキシ設定を使用しません。