ローカル NTLM プロキシヘルパー：クライアントアクセスと上流ログイン

アプリケーションは自分のコンピュータ上のプロキシに接続します。そのヘルパーが次に社内プロキシに対して認証します。アプリケーション自身が社内の認証交換を行っているとは限りません。

application → local helper → company proxy → destination

CNTLM のようなヘルパーには上流アカウントとプロキシの設定があります。そのローカルリスナーには別個の到達性とアクセスの境界があります。別のエンドポイントに対して入力したブラウザのパスワードは、どちらも自動的には設定しません。

失敗した区間を特定する

まず、アプリケーションがヘルパーの実際のリスナーとプロトコルを選んだことを確認します。そのリスナーに届く前のエラーは NTLM の失敗ではありません。次に、ヘルパーが設定された親に到達したか、親がその ID を受け入れたかを調べます。

この経路で返る 407 には原因の切り分けが必要です。表示されるステータスがアプリケーションの送るべきアカウントを示すと決めつけず、ローカルのトランザクションをヘルパーの秘匿化された診断情報と突き合わせます。

古い例では keep-alive ヘッダーを追加して成功を報告することがあります。接続指向の認証では持続性が重要になり得ますが、その観察は、失敗したすべてのヘルパー設定に同じヘッダーが必要だと証明するものではありません。エンドポイントの選択、対応する方式、アカウント、接続の寿命は別々の入力であり続けます。

リスナーは実在のサービス

ループバックはリスナーを周囲のネットワークから切り離しますが、そのコンピュータ上のすべてのプロセスやユーザーを区別するわけではありません。ゲートウェイやより広いバインドは、ヘルパーの上流 ID を使い得る呼び出し元の集合を変えます。その変更は意図して行ってください。

アプリケーションが必要な方式を実行できない場合は、承認されたヘルパーの構成を使ってください。有用な結果は、アカウントの帰属が既知の既知の経路であり、たまたま 1 つのダウンロードが通るだけの説明のつかない追加サービスではありません。