کئی درخواستیں کمپنی کی پراکسی کے ذریعے Kerberos کامیابی سے استعمال کرتی ہیں۔ ایک درخواست پاس ورڈ کی طلب پیدا کرتی ہے۔ keytab تبدیل کرنے سے پہلے دیکھیں کہ اس مخصوص درخواست نے کون سی تصدیق کی پالیسی منتخب کی۔

گیٹ وے پالیسی کے ذریعے دائرہ اور معاون اسکیمیں منتخب کر سکتا ہے۔ ایک ہی براؤزر سے ایک ہی پراکسی تک پہنچنے والے دو لین دین کو یکساں تصدیق کی شرائط ملنا ضروری نہیں۔

اس فرضی سراغ پر غور کریں:

لین دینپہلا مماثل پالیسی قاعدہدستیاب تصدیق
بنیادی دستاویززیر انتظام براؤزنگ قاعدہNegotiate
دوسرے ہوسٹ سے اسکرپٹپہلے کی منزل کا استثناBasic یا NTLM

پہلا کامیاب تبادلہ دکھاتا ہے کہ ایک منتخب راستہ کام کرتا ہے۔ یہ نہیں دکھاتا کہ دوسرا لین دین اس راستے تک پہنچا۔ اسناد درست ہو سکتی ہیں جبکہ اس کی تصدیق کا طریقہ منتخب کرنے والا قاعدہ غلط ہو۔

منتخب قاعدہ اور اس کی ترتیب کا جائزہ لیں

چیلنج شدہ درخواست کی منزل اور وقت کو گیٹ وے کے پالیسی سراغ سے منسلک کریں۔ پہلے قابلِ اطلاق قاعدے کے بنائے ہوئے دائرے، اسکیم کے انتخاب اور تصدیق کے موڈ کی نشاندہی کریں۔ ان اقدار کا اسی کلائنٹ کی کامیاب درخواست سے موازنہ کریں۔

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

اگر وسیلہ غیر ارادی استثنا میں آ گیا ہے تو اس قاعدے یا اس کے دائرے کو درست کریں اور نتیجے کا سراغ دیکھیں۔ ہر جگہ مجاز تصدیق کے طریقے وسیع کرنا عدم مطابقت کو چھپا سکتا ہے، لیکن غیر متعلق ٹریفک کے رسائی رویے کو بدل دیتا ہے۔

اگر مطلوبہ دائرہ منتخب ہو اور متوقع تبادلہ ناکام ہو تو اکاؤنٹ اور Kerberos کے شواہد کی طرف بڑھیں۔ تب ہی ٹکٹ، سروس کا نام یا بیک اینڈ تشخیص متعلقہ ہوتے ہیں۔

متعلقہ مضامین