curl の NTLM プロキシログインを診断する
NTLM プロキシがログインを拒否するとき、curl のビルドの対応状況、プロキシの認証チャレンジ、接続の継続性を確認します。
NTLM プロキシ認証にはハンドシェイクがあり、ユーザー名を一度付けるだけではありません。アカウントのパスワードを変更する前に、プロキシが実際に NTLM を提示していることと、使用する curl バイナリが対応していることを確認します。
curl --version
リクエストを実行するバイナリの機能一覧を確認します。別にインストールされた curl、コンテナイメージ、OS のビルドでは、対応する認証が異なる場合があります。
プロキシ専用の認証方式を選ぶ
curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/
エンドポイント、ドメイン、ユーザー名は例です。管理者から指定された形式を使ってください。引数にパスワードを含めなければ、表示されるコマンドに秘密を残さず、curl に入力を求めさせることができます。
最初の認証チャレンジは交渉の一部である場合があります。完了したハンドシェイクが拒否される場合とは区別します。プロキシのチャレンジに応答するために、オリジンサーバー用の NTLM オプションを使わないでください。
接続の動作も診断に含める
NTLM は接続単位の状態を持ちます。ハンドシェイクは想定された接続経路で進める必要があり、各段階の間で接続を繰り返し入れ替えると完了できなくなる場合があります。
libcurl を使うアプリケーションでは、認証と接続の再利用をライブラリに任せます。異なる ID で認証済みの接続を交換可能と扱う汎用プールを作らないでください。複数の中継点や仲介サービスがある場合は、必要な接続構成を維持するか確認します。
対応状況と方式の選択が正しければ、アカウント形式、ドメインポリシー、機密情報を除去したサーバーの認証ログを調べます。認証チャレンジが出る前のタイムアウトは到達性の問題であり、NTLM パスワードが誤っていた証拠ではありません。
詳細トレースには認証トークンや内部名が含まれる場合があります。ローカルで使用し、共有する前に機密情報を除去してください。公開のエラー報告に生のトークン交換は不要です。