Utilisez le nom d’hôte du proxy pour l’authentification Negotiate de curl
Conservez l’identité de service enregistrée du proxy lors du diagnostic d’une connexion Negotiate, au lieu de supposer que son adresse IP est un nom équivalent.
Utilisez le nom du proxy fourni pour le déploiement Negotiate. Une connexion TCP à son adresse IP n’établit pas que la même identité d’authentification sera demandée.
curl --proxy http://proxy.example:3128 --proxy-negotiate --proxy-user : --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/Remplacez le nom d’hôte du proxy par le nom de service approuvé. Cela sélectionne Negotiate pour le proxy avec les identifiants disponibles sur la plateforme ; cela ne crée pas de connexion au domaine et n’obtient pas de tickets auprès d’un service d’authentification indisponible.
Pour un déploiement qui attend HTTP/proxy.example, une adresse IP ou un autre alias peut modifier l’identité de service demandée. Certains environnements prennent explicitement en charge d’autres modes de nommage ; conservez donc l’identité configurée au lieu de déclarer l’authentification par IP impossible partout.
Vérifiez le binaire curl réellement utilisé et l’environnement du compte. La prise en charge de GSSAPI ou SSPI dépend de la plateforme et de la compilation. Si le déploiement exige un composant de service particulier, utilisez l’option curl de nom de service du proxy selon la configuration enregistrée ; deviner les noms peut déplacer l’échec au lieu de le résoudre.
Negotiate est lui-même une étiquette de négociation de mécanisme. Sa présence seule ne permet pas de savoir quel mécanisme sous-jacent a été choisi. Utilisez des diagnostics client/serveur autorisés lorsque cette distinction compte et gardez tickets et jetons hors des rapports partagés.