Diagnostiquer une connexion à un proxy NTLM dans curl
Si un proxy NTLM refuse la connexion, vérifiez les fonctions de curl, le défi du proxy et la continuité de la connexion.
L’authentification d’un proxy NTLM comporte un échange de négociation, pas seulement l’ajout ponctuel d’un nom d’utilisateur. Avant de changer le mot de passe du compte, vérifiez que le proxy propose bien NTLM et que le binaire curl le prend en charge.
curl --version
Examinez la liste des fonctions du binaire qui exécute votre requête. Une autre installation de curl, une image de conteneur ou une compilation du système d’exploitation peut prendre en charge d’autres authentifications.
Choisir une méthode propre au proxy
curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/
Le point de terminaison, le domaine et le nom d’utilisateur sont des exemples. Utilisez le format fourni par votre administrateur. Sans mot de passe dans l’argument, curl peut le demander au lieu de laisser le secret dans la commande affichée.
Un défi d’authentification initial peut faire partie de la négociation. Distinguez-le d’un refus après un échange terminé. N’utilisez pas une option NTLM destinée au serveur d’origine pour répondre au défi d’un proxy.
Inclure le comportement des connexions dans le diagnostic
NTLM possède un état lié à la connexion. L’échange doit se dérouler sur le chemin de connexion attendu ; remplacer les connexions à répétition entre ses étapes peut empêcher son achèvement.
Pour une application utilisant libcurl, laissez la bibliothèque gérer l’authentification et la réutilisation des connexions. Ne créez pas un pool générique qui traite comme interchangeables des connexions authentifiées pour des identités différentes. En présence de plusieurs relais ou d’un service intermédiaire, vérifiez qu’il préserve l’organisation des connexions requise.
Si la prise en charge et le choix de méthode sont corrects, examinez le format du compte, la stratégie de domaine et les journaux d’authentification expurgés du serveur. Un délai dépassé avant tout défi reste un problème d’accessibilité, pas la preuve d’un mauvais mot de passe NTLM.
Les traces détaillées peuvent contenir des jetons d’authentification et des noms internes. Utilisez-les localement et expurgez-les avant de les partager ; un rapport d’erreur public n’a pas besoin de l’échange brut de jetons.