مقامی NTLM پراکسی مددگار: کلائنٹ رسائی بمقابلہ اپ اسٹریم لاگ ان

آپ کی ایپ اپنے کمپیوٹر پر موجود پراکسی سے جڑتی ہے۔ پھر وہ مددگار کمپنی کی پراکسی سے تصدیق کرتا ہے۔ ضروری نہیں کہ ایپ خود کمپنی کی تصدیق کی تبدیلی کرے۔

application → local helper → company proxy → destination

CNTLM جیسے مددگار کے پاس اپ اسٹریم اکاؤنٹ اور پراکسی کنفیگریشن ہوتی ہے۔ اس کے مقامی سننے والے کی الگ رسائی اور پہنچ کی حد ہوتی ہے۔ کسی دوسرے اینڈ پوائنٹ کے لیے براؤزر میں ڈالا گیا پاس ورڈ دونوں میں سے کسی کو خودکار طور پر کنفیگر نہیں کرتا۔

شناخت کریں کہ کون سا مرحلہ ناکام ہوا

پہلے تصدیق کریں کہ ایپ نے مددگار کا اصل سننے والا اور پروٹوکول منتخب کیا ہے۔ اس سننے والے تک پہنچنے سے پہلے کی خرابی NTLM ناکامی نہیں ہے۔ پھر جانچیں کہ مددگار اپنے کنفیگر شدہ والد تک پہنچا اور والد نے اس کی شناخت قبول کی۔

اس راستے پر واپس آنے والا 407 انتساب کا متقاضی ہے۔ یہ فرض کرنے کے بجائے کہ نظر آنے والی حالت وہ اکاؤنٹ بتاتی ہے جو آپ کی ایپ کو بھیجنا چاہیے، مقامی لین دین کو مددگار کی ترمیم شدہ تشخیص سے جوڑیں۔

پرانی مثالیں کبھی کبھی keep-alive ہیڈر شامل کر کے کامیابی رپورٹ کرتی ہیں۔ کنکشن پر مبنی تصدیق میں تسلسل اہم ہو سکتا ہے، لیکن وہ مشاہدہ یہ ثابت نہیں کرتا کہ ہر ناکام مددگار سیٹ اپ کو وہی ہیڈر درکار ہے۔ اینڈ پوائنٹ کا انتخاب، معاون طریقہ، اکاؤنٹ اور کنکشن کی عمر الگ ان پٹ رہتے ہیں۔

سننے والا ایک حقیقی سروس ہے

Loopback سننے والے کو اردگرد کے نیٹ ورک سے دور رکھتا ہے؛ یہ اس کمپیوٹر کے تمام عمل یا صارفین میں فرق نہیں کرتا۔ گیٹ وے یا زیادہ وسیع بائنڈنگ ان کال کرنے والوں کا مجموعہ بدل دیتی ہے جو ممکنہ طور پر مددگار کی اپ اسٹریم شناخت استعمال کر سکتے ہیں۔ یہ تبدیلی جان بوجھ کر کریں۔

جب ایپ مطلوبہ اسکیم نہ کر سکے تو منظور شدہ مددگار ترتیب استعمال کریں۔ مفید نتیجہ معلوم اکاؤنٹ ملکیت والا معلوم راستہ ہے، نہ کہ کوئی غیر واضح اضافی سروس جو اتفاقاً ایک ڈاؤن لوڈ کو کام کرنے لگے۔