أستكشاف أخطاء مصادقة Kerberos وإصلاحها على SWA

المقدمة

يصف هذا المستند أساسيات مصادقة Kerberos والخطوات الخاصة باستكشاف أخطاء مصادقة Kerberos وإصلاحها في جهاز ويب الآمن (SWA).

المصطلح

• سوا: ‪Secure Web Appliance‬ (جهاز حماية الويب)
• CLI: واجهة سطر الأوامر
• إعلان: الدليل النشط
• دي سي: وحدة التحكم بالمجال
• SPN: اسم الخدمة الأساسي
• كي دي سي: مركز توزيع مفتاح Kerberos
• TGT: بطاقة منح التذكرة (بطاقة المصادقة)
• TGS: خدمة منح التذاكر
• ها: الإتاحة العالية
• بروتوكول VRRP: بروتوكول تكرار جهاز التوجيه الظاهري
• كارب: بروتوكول تكرار العنوان الشائع
• SPN: اسم الخدمة الأساسي
• LDAP: البروتوكول الخفيف للوصول للدليل

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• المصادقة والمعالجات على SWA
• Active Directory ومصادقة Kerberos

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

تدفق شبكة Kerberos

الصورة: نموذج تدفق شبكة Kerberos

هذه هي الخطوات الأساسية للمصادقة في بيئة Kerberized:

1. يطلب العميل TGT من شركة KDC.

2. تقوم شركة KDC بالتحقق من بيانات اعتماد مستخدم جهاز العميل وإعادة إرسال مفتاح TGT ومفتاح جلسة عمل مشفر.

3. يتم تشفير TGT باستخدام المفتاح السري TGS.

4. يقوم العميل بتخزين إجمالي تكلفة الملكية (TGT) ويطلب تلقائيا الحصول على اسم جديد عند انتهاء صلاحيته.

للوصول إلى خدمة أو مورد:

1. يرسل العميل TGT إلى TGS مع SPN الخاص بالمورد المطلوب.
2. يتحقق مركز التحكم في الشبكة من TGT ويتحقق من حقوق الوصول إلى جهاز عميل المستخدم.

3. يرسل TGS مفتاح جلسة عمل خاص بالخدمة إلى العميل.
4. يوفر العميل مفتاح الجلسة للخدمة لإثبات الوصول، وتتيح الخدمة الوصول.

تدفق مصادقة Kerberos في SWA

1. يطلب العميل الوصول إلى www.google.com من خلال SWA.

2. تستجيب الوحدة النمطية للنظام الأساسي الموثوق به (SWA) بحالة HTTP 407، طالبة المصادقة.

3. يطلب العميل تذكرة خدمة من خادم AD لخدمة HTTP/SWA.domain.com باستخدام TGT الذي يحصل عليه أثناء الانضمام للمجال.

4. يتحقق خادم AD من صحة العميل ويصدر تذكرة خدمة، في حال نجاحها وتم العثور على SPN الخاص ب SWA، ينتقل إلى الخطوة التالية.

5. يرسل العميل هذه التذكرة إلى SWA.

6. تقوم SWA بفك تشفير التذكرة والتحقق من المصادقة.

7. في حالة نجاح المصادقة، يتحقق SWA من السياسات.

8. ترسل SWA إستجابة HTTP 200 OK إلى العميل إذا كانت المعاملة مسموح بها.

ما هو الغرض من SPN؟

يقوم SPN بتعريف مثيل خدمة بشكل فريد في مصادقة Kerberos. وهو يربط مثيل الخدمة بحساب خدمة، مما يسمح للعملاء بطلب المصادقة للخدمة بدون اسم الحساب. يحتوي كل حساب في تنفيذ KDC، مثل AD أو OpenLDAP، على SPN. في حين أن شبكة SPN تحدد الخدمة بشكل صارم، فإنها تستخدم بشكل خاطئ أحيانا للإشارة إلى اسم العميل (UPN) في السيناريوهات التي تعمل فيها الخدمة أيضا كعميل.

في Kerberos، تعرف شبكة SPN بشكل فريد مثيل خدمة داخل شبكة. وهو يسمح للعملاء بطلب المصادقة لخدمة معينة. يربط SPN مثيل الخدمة بحسابه، مما يمكن Kerberos من المصادقة بشكل صحيح وتخويل طلبات الوصول إلى تلك الخدمة.

تكوين خادم Active Directory

1. إنشاء حساب مستخدم جديد أو إختيار حساب مستخدم موجود لاستخدامه.

2. سجل SPN المراد إستخدامه مقابل حساب المستخدم المختار.

3. تأكد من عدم تسجيل أي شبكات SPN مكررة.

تلميح: كيف يختلف Kerberos مع SWA خلف موازن التحميل أو مدير حركة مرور/شاحن حركة مرور؟

• بدلا من اقتران SPN ل HA Virtual Hostname بحساب مستخدم، قم بإقران SPN لجهاز إعادة توجيه حركة مرور HTTP (على سبيل المثال، موازن التحميل أو مدير حركة المرور) بحساب مستخدم على AD.

يمكن العثور على أفضل الممارسات لتنفيذ Kerberos:

• أفضل ممارسات جهاز الويب الآمن 
• تكوين منافذ جدار الحماية لاتصالات SWA 

استكشاف الأخطاء وإصلاحها

أستكشاف أخطاء Kerberos وإصلاحها باستخدام أوامر SPN

هذه قائمة من أوامر setSPN المفيدة لإدارة شبكات SPN في بيئة Kerberos. يتم تشغيل هذه الأوامر عادة من واجهة سطر أوامر ذات امتيازات إدارية في بيئة Windows.

setspn -L 

setspn -A  

setspn -D  

setspn -Q 

setspn -L 

setspn -S  

setspn -R 

أمثلة على أوامر ومخرجات SPN

الأمثلة المقدمة توضح الاستخدام:

• حساب المستخدم/الكمبيوتر: vrpServiceUser
• SPN: http/WsaHostname.com أو http/proxyha.localdomain

التحقق مما إذا كان SPN مقترنا بالفعل بحساب مستخدم:

setspn -q 

setspn -q http/proxyha.localdomain

السيناريو 1: SPN غير موجود.

السيناريو الثاني: تم العثور على SPN.

• إقران SPN بحساب مستخدم/كمبيوتر صالح:

setspn -s  

على سبيل المثال: 

setspn -s http/proxyha.localdomain vrrpserviceuser 

• حذف/إزالة SPN مقترن بالفعل بمستخدم أو حساب كمبيوتر:

setspn -d  

على سبيل المثال: 

setspn -d http/proxyha.localdomain pod1234-wsa0

تأكد من عدم وجود شبكات SPN مكررة لاسم المضيف الظاهري HA، حيث يمكن أن تحدث حالات الفشل لاحقا.

• الأمر المطلوب تشغيله:

setspn –x

ونتيجة لذلك، لا يتم توفير تذكرة خدمة Kerberos للعميل، وتفشل مصادقة Kerberos.

تحذير: إذا تم العثور على تكرارات، فقم بإزالة التكرارات التي تشغل الأمر setSPN -d.

• سرد كافة SPNs المقترنة بحساب:

 setspn –l 

على سبيل المثال:

setspn –l vrrpserviceuser

أستكشاف أخطاء Kerberos وإصلاحها على SWA

يتطلب دعم Cisco معلومات عند أستكشاف أخطاء مصادقة Kerberos وإصلاحها:

• تفاصيل التكوين الحالي
• سجلات المصادقة (يفضل أن تكون في وضع تصحيح الأخطاء أو التتبع)
• التقاط الحزم التي تم تنفيذها (مع عوامل التصفية المناسبة):
  • جهاز العميل
  • سوا
•  الوصول إلى السجلات مع تمكين محدد التنسيق المخصص ٪m. يجب أن يعرض هذا آلية المصادقة التي تم إستخدامها لمعاملة معينة.
• للحصول على تفاصيل مصادقة مفصلة، أضف هذه الحقول المخصصة إلى سجلات الوصول على الوكلاء العاملين/غير العاملين لاسترداد معلومات إضافية أو ارجع إلى إضافة معلمات في سجلات الوصول.
• في واجهة المستخدم الرسومية SWA، انتقل إلى إدارة النظام > تسجيل الاشتراك > سجلات الوصول > حقول مخصصة > إضافة هذه السلسلة لمشاكل المصادقة:

server IP address = %k, Client IP address= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Auth response = %:a;

• سجل وصول SWA لتفاصيل مصادقة المستخدم.
• سجلات SWA من Cisco بأسماء المستخدمين التي تمت مصادقتها في تنسيق المجال\username@authentication_realm:

• قم بتشغيل إعدادات مجال مصادقة الاختبار من واجهة المستخدم الرسومية (GUI). انتقل إلى الشبكة > المصادقة، ثم انقر على اسم المجال الخاص بك في قسم إختبار الإعدادات الحالية.
• انقر على بدء الاختبار.

لم يتم العثور على الخادم في قاعدة بيانات Kerberos

إحدى حالات الخطأ الشائعة هي فشل طلبات الويب مع عدم العثور على الخادم في قاعدة بيانات Kerberos":

curl -vx proxyha.local:3128 --proxy-negotiate -u: http://www.cisco.com/
* About to connect() to proxy proxyha.localdomain port 3128 (#0)
* Connected to proxyha.local (10.8.96.30) port 3128 (#0)
< HTTP/1.1 407 Proxy Authentication Required
< Via: 1.1 pod1234-wsa02.local:80 (Cisco-SWA/10.1.2-003)
< Content-Type: text/html
gss_init_sec_context() failed: : Server not found in Kerberos database
< Proxy-Authenticate: Negotiate
< Connection: close
* HTTP/1.1 proxy connection set close!

في هذه الحالة، يشير الخطأ إلى أن اسم الخدمة الأساسي المتوافق مع قيمة عنوان الوكيل proxy.local غير مسجل على خادم Active Directory. لحل هذه المشكلة، من الضروري تأكيد تسجيل SPN http/proxyha.local على AD DC وإضافته إلى حساب خدمة مناسب.

المحتوى ذي الصلة

• تكوين جهاز ويب الآمن للسماح بوصول الضيف 
• تكوين مصادقة Active Directory في SWA 
• تكوين مصادقة تسجيل الدخول الأحادي ل Kerberos في SWA 
• تجاوز حركة المرور في جهاز ويب الآمن