لماذا يطلب طلب وكيل واحد كلمة مرور بينما يعمل Kerberos مع طلبات أخرى

تستخدم عدة طلبات Kerberos بنجاح عبر وكيل الشركة. ويُنتج طلب واحد مطالبة بكلمة مرور. قبل استبدال keytab، تحقّق من سياسة المصادقة التي اختارها ذلك الطلب تحديدًا.

يمكن للبوابة أن تختار نطاقًا ومخططات مدعومة عبر السياسة. ولا يلزم أن تتلقى معاملتان تصلان إلى الوكيل نفسه من المتصفح نفسه متطلبات مصادقة متطابقة.

تأمّل هذا التتبع الافتراضي:

يُظهر التبادل الناجح الأول أن مسارًا مختارًا واحدًا يعمل، لكنه لا يُظهر أن المعاملة الثانية وصلت إلى ذلك المسار. قد تكون بيانات الاعتماد صالحة بينما القاعدة التي تختار آلية المصادقة خاطئة.

افحص القاعدة المختارة وترتيبها

اربط وجهة الطلب المتحدّى ووقته بتتبع السياسة في البوابة. حدّد النطاق وخيارات المخطط ووضع المصادقة التي تنتجها أول قاعدة منطبقة، ثم قارن تلك القيم بطلب ناجح من العميل نفسه.

كذلك قد تتصرف سياسة مبنية على هوية مرتبطة بعنوان IP بشكل مختلف عن سياسة تتطلب المصادقة على الاتصال. لا تفترض أن غياب مصافحة جديدة يعني اختيار النطاق نفسه.

إذا وقع المورد في استثناء غير مقصود، فصحّح تلك القاعدة أو نطاقها وراجع التتبع الناتج. إن توسيع أساليب المصادقة المسموح بها في كل مكان قد يخفي عدم التطابق مع تغيير سلوك الوصول لحركة غير ذات صلة.

إذا اختير النطاق المقصود وفشل التبادل المتوقع، فانتقل إلى أدلة الحساب وKerberos. عندئذ تصبح التذكرة أو اسم الخدمة أو تشخيصات الخلفية ذات صلة.