curl में NTLM प्रॉक्सी लॉगिन का निदान

NTLM प्रॉक्सी प्रमाणीकरण में हैंडशेक होता है, केवल एक बार उपयोगकर्ता नाम जोड़ना नहीं। खाते का पासवर्ड बदलने से पहले पुष्टि करें कि प्रॉक्सी वास्तव में NTLM प्रदान करता है और curl बाइनरी उसका समर्थन करती है।

curl --version

अनुरोध चलाने वाली बाइनरी की सुविधाओं की सूची देखें। किसी अन्य curl इंस्टॉलेशन, कंटेनर इमेज या ऑपरेटिंग सिस्टम बिल्ड में प्रमाणीकरण समर्थन अलग हो सकता है।

प्रॉक्सी के लिए विशिष्ट प्रमाणीकरण विधि चुनें

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 इस्तेमाल करने वाले ऐप्लिकेशन में लाइब्रेरी को प्रमाणीकरण और कनेक्शन का पुनः उपयोग संभालने दें। अलग पहचानों के लिए प्रमाणित कनेक्शन को परस्पर बदलने योग्य मानने वाला सामान्य पूल न बनाएँ। कई हॉप या मध्यस्थ सेवा के लिए जाँचें कि आवश्यक कनेक्शन व्यवस्था बनी रहती है या नहीं।

समर्थन और विधि का चुनाव सही हो तो खाता प्रारूप, डोमेन नीति और सर्वर के संवेदनशील डेटा हटाए गए प्रमाणीकरण लॉग जाँचें। किसी चुनौती से पहले टाइमआउट होना अब भी पहुँच की समस्या है, गलत NTLM पासवर्ड का प्रमाण नहीं।

विस्तृत ट्रेस में प्रमाणीकरण टोकन और आंतरिक नाम हो सकते हैं। उन्हें स्थानीय रूप से इस्तेमाल करें और साझा करने से पहले संवेदनशील डेटा हटाएँ; सार्वजनिक त्रुटि रिपोर्ट में टोकन की कच्ची अदला-बदली ज़रूरी नहीं है।