curl میں NTLM پراکسی لاگ اِن کی تشخیص
NTLM پراکسی لاگ اِن مسترد کرے تو curl بلڈ کی معاونت، پراکسی کا تصدیقی چیلنج اور کنکشن کا تسلسل جانچیں۔
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 پاس ورڈ کا ثبوت نہیں۔
تفصیلی ٹریس میں تصدیقی ٹوکن اور اندرونی نام ہو سکتے ہیں۔ انہیں مقامی طور پر استعمال کریں اور شیئر کرنے سے پہلے حساس ڈیٹا ہٹائیں؛ عوامی خرابی رپورٹ کو ٹوکن کا خام تبادلہ درکار نہیں۔