curl の Negotiate 認証ではプロキシのホスト名を使う

Negotiate の展開で指定されたプロキシ名を使います。IP アドレスへの TCP 接続だけでは、同じ認証 ID が要求されることは確定しません。

curl --proxy http://proxy.example:3128 --proxy-negotiate --proxy-user : --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/

プロキシのホスト名を承認済みのサービス名に置き換えます。これにより、プラットフォームで利用できる資格情報の構成を使ってプロキシ Negotiate が選択されます。ドメインログインを作成したり、利用できない認証サービスからチケットを取得したりする処理ではありません。

HTTP/proxy.exampleを想定する展開では、IP や別の別名を使うと要求されるサービス ID が変わることがあります。別の名前構成を明示的にサポートする環境もあるため、IP 認証は常に不可能だと決めつけず、設定済みの ID を維持してください。

実際に使われている curl バイナリとアカウント環境を確認します。GSSAPI や SSPI の対応はプラットフォームとビルドに依存します。特定のサービス要素が必要な場合は、登録済みの設定に従って curl のプロキシサービス名オプションを使います。名前を推測すると、失敗を解決せずに別の場所へ移すことがあります。

Negotiateはそれ自体がメカニズム交渉のラベルです。表示されただけでは、どの基盤メカニズムが選ばれたかは分かりません。区別が重要な場合は許可されたクライアント/サーバー診断を使い、チケットやトークンを共有レポートに含めないでください。