أستكشاف الأخطاء وإصلاحها في الوصول إلى الموارد الخاصة باستخدام مصادقة Kerberos
المقدمة
يصف هذا المستند سلوك Kerberos عند إستخدامه مع Secure Access Zero Trust Network Access (ZTNA).
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- الوصول الآمن
- Cisco Secure Client
- أنفاق بروتوكول أمان الإنترنت (IPSec)
- شبكة الوصول عن بعد الخاصة الظاهرية (RAVPN)
- الوصول إلى الشبكة دون ثقة (ZTNA)
معلومات أساسية
يتم إستخدام الوصول الآمن في توفير الوصول إلى التطبيقات الخاصة من خلال سيناريوهات متعددة بما في ذلك وحدة الوصول إلى موقع Zero Trust (ZTNA) على العميل الآمن أو نفق IPSec أو شبكة VPN للوصول عن بعد. بينما توفر التطبيقات الخاصة آلية المصادقة الخاصة بها، فهناك قيود على الخوادم التي تعتمد على Kerberos كآلية مصادقة.
تدفق حزم Kerberos
المشكلة: فشل في الوصول إلى الموارد الخاصة باستخدام مصادقة Kerberos
سيؤدي بدء طلب مصادقة من جهاز عميل خلف وحدة ZTNA النمطية إلى تطبيق خاص خلف App Connector إلى تغيير عنوان IP المصدر على مسار شبكة الوصول الآمن. مما يؤدي إلى فشل المصادقة عند إستخدام تذكرة Kerberos التي بدأها مركز توزيع Kerberos للعملاء (KDC).
الحل
يعد عنوان IP لمصدر العميل جزءا من تذاكر Kerberos التي تم منحها من مركز توزيع Kerberos (KDC). بشكل عام عند إجتياز تذاكر Kerberos عبر شبكة، فمن المطلوب أن يظل عنوان IP للمصدر دون تغيير، وإلا فإن خادم الوجهة الذي تتم مصادقته معه، لا يفي بالتذكرة عند مقارنته بعنوان IP للمصدر الذي تم إرساله منه.
لحل هذه المشكلة أستخدم أحد الخيارات:
الخيار 1:
قم بتعطيل الخيار لتضمين عنوان IP المصدر في تذكرة Kerberos للعميل.
الخيار 2:
إستخدام شبكة VPN للوصول الآمن باستخدام الموارد الخاصة خلف نفق IPSec بدلا من التطبيقات الخاصة خلف App Connector.
ملاحظة: يؤثر هذا السلوك فقط على التطبيقات الخاصة التي يتم نشرها خلف App Connector ويتم الحصول على حركة مرور البيانات من العميل باستخدام وحدة ZTNA النمطية بدون VPN.
ملاحظة: يظهر "البحث عن نشاط الوصول الآمن" الإجراء المسموح به للمعاملة، نظرا لأن الكتلة تحدث على جانب التطبيق الخاص وليس على "الوصول الآمن".
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
19-Aug-2024 |
الإصدار الأولي |
التعليقات