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 पासवर्डचा पुरावा नाही.

तपशीलवार ट्रेसमध्ये प्रमाणीकरण टोकन आणि अंतर्गत नावे असू शकतात. त्यांचा स्थानिक वापर करा आणि शेअर करण्यापूर्वी संवेदनशील माहिती काढा; सार्वजनिक त्रुटी अहवालाला टोकनची कच्ची देवाणघेवाण आवश्यक नाही.