Використовуйте ім’я проксі, надане для розгортання Negotiate. TCP-з’єднання з його IP не встановлює, що буде запитано ту саму ідентичність автентифікації.

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

Замініть ім’я хоста проксі схваленим ім’ям служби. Так обирається proxy Negotiate із використанням доступної на платформі схеми облікових даних; вхід до домену не створюється, а квитки не отримуються від недоступної служби автентифікації.

У розгортанні, що очікує HTTP/proxy.example, IP або інший псевдонім може змінити запитувану ідентичність служби. Деякі середовища явно підтримують інші способи іменування, тому зберігайте налаштовану ідентичність, а не оголошуйте автентифікацію через IP всюди неможливою.

Перевірте фактичний бінарний файл curl і середовище облікового запису. Підтримка GSSAPI або SSPI залежить від платформи та збірки. Якщо розгортанню потрібен певний компонент служби, використовуйте опцію імені служби проксі в curl відповідно до зареєстрованої конфігурації; вгадування імен може лише перемістити помилку.

Negotiate — це сама мітка узгодження механізму. Її наявність не визначає, який базовий механізм обрано. Коли різниця важлива, використовуйте авторизовану діагностику клієнта/сервера, а квитки й токени тримайте поза спільними звітами.

Схожі статті