ایک پراکسی درخواست پاس ورڈ کیوں مانگتی ہے جبکہ دیگر کے لیے Kerberos کام کرتا ہے
وہ پالیسی قاعدہ تلاش کریں جو ایک درخواست کو غیر متوقع پراکسی تصدیق کا دائرہ تفویض کرتا ہے، چاہے دیگر درخواستیں Kerberos کامیابی سے استعمال کریں۔
کئی درخواستیں کمپنی کی پراکسی کے ذریعے Kerberos کامیابی سے استعمال کرتی ہیں۔ ایک درخواست پاس ورڈ کی طلب پیدا کرتی ہے۔ keytab تبدیل کرنے سے پہلے دیکھیں کہ اس مخصوص درخواست نے کون سی تصدیق کی پالیسی منتخب کی۔
گیٹ وے پالیسی کے ذریعے دائرہ اور معاون اسکیمیں منتخب کر سکتا ہے۔ ایک ہی براؤزر سے ایک ہی پراکسی تک پہنچنے والے دو لین دین کو یکساں تصدیق کی شرائط ملنا ضروری نہیں۔
اس فرضی سراغ پر غور کریں:
| لین دین | پہلا مماثل پالیسی قاعدہ | دستیاب تصدیق |
|---|---|---|
| بنیادی دستاویز | زیر انتظام براؤزنگ قاعدہ | Negotiate |
| دوسرے ہوسٹ سے اسکرپٹ | پہلے کی منزل کا استثنا | Basic یا NTLM |
پہلا کامیاب تبادلہ دکھاتا ہے کہ ایک منتخب راستہ کام کرتا ہے۔ یہ نہیں دکھاتا کہ دوسرا لین دین اس راستے تک پہنچا۔ اسناد درست ہو سکتی ہیں جبکہ اس کی تصدیق کا طریقہ منتخب کرنے والا قاعدہ غلط ہو۔
منتخب قاعدہ اور اس کی ترتیب کا جائزہ لیں
چیلنج شدہ درخواست کی منزل اور وقت کو گیٹ وے کے پالیسی سراغ سے منسلک کریں۔ پہلے قابلِ اطلاق قاعدے کے بنائے ہوئے دائرے، اسکیم کے انتخاب اور تصدیق کے موڈ کی نشاندہی کریں۔ ان اقدار کا اسی کلائنٹ کی کامیاب درخواست سے موازنہ کریں۔
IP سے منسلک شناخت پر مبنی پالیسی بھی کنکشن پر تصدیق مانگنے والی پالیسی سے مختلف برتاؤ کر سکتی ہے۔ یہ نہ سمجھیں کہ نیا ہینڈ شیک نہ ہونے کا مطلب وہی دائرہ منتخب ہونا ہے۔
اگر وسیلہ غیر ارادی استثنا میں آ گیا ہے تو اس قاعدے یا اس کے دائرے کو درست کریں اور نتیجے کا سراغ دیکھیں۔ ہر جگہ مجاز تصدیق کے طریقے وسیع کرنا عدم مطابقت کو چھپا سکتا ہے، لیکن غیر متعلق ٹریفک کے رسائی رویے کو بدل دیتا ہے۔
اگر مطلوبہ دائرہ منتخب ہو اور متوقع تبادلہ ناکام ہو تو اکاؤنٹ اور Kerberos کے شواہد کی طرف بڑھیں۔ تب ہی ٹکٹ، سروس کا نام یا بیک اینڈ تشخیص متعلقہ ہوتے ہیں۔