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 पासवर्डको प्रमाण होइन।

विस्तृत ट्रेसमा प्रमाणीकरण टोकन र आन्तरिक नाम हुन सक्छन्। तिनलाई स्थानीय रूपमा प्रयोग गर्नुहोस् र साझा गर्नुअघि संवेदनशील डेटा हटाउनुहोस्; सार्वजनिक त्रुटि प्रतिवेदनलाई टोकनको कच्चा आदानप्रदान चाहिँदैन।

सम्बन्धित लेखहरू