الملخص
يتم تضمين الحماية ل CVE-2022-21920 في تحديثات 11 يناير 2022 Windows وتحديثات Windows اللاحقة. تحتوي هذه التحديثات على منطق محسن للكشف عن هجمات تخفيض الدرجات للأسماء الأساسية للخدمة من 3 جزء عند استخدام بروتوكول مصادقة Microsoft Negotiate.
توفر هذه المقالة إرشادات عندما لا تكون مصادقة Kerberos ناجحة.
مزيد من المعلومات
قد يؤدي تثبيت تحديثات 11 يناير 2022 Windows وتحديثات Windows اللاحقة إلى فشل المصادقة ل SPN التي من 3 جزئين حيث لم تنجح مصادقة Kerberos. بالنسبة إلى هذه البيئات، من المرجح أن مصادقة Kerberos ل SPN ذات 3 جزء لم تعمل لبعض الوقت. قد ترى الحدث التالي على Windows العميل للمساعدة في الفرز.
|
لقطة شاشة لحدث LSA 40970 تحدد صورة NTLM البديلة ل SPN معين من بيئة اختبار Microsoft. |
إصدار النص لحدث LSA 40970 |
|
|
كشف نظام الأمان عن محاولة تخفيض الدرجات عند الاتصال ب SPN من 3 جزء <اسم SPN> مع رمز الخطأ "قاعدة بيانات SAM على Windows Server لا تحتوي على حساب كمبيوتر لعلاقة الثقة في محطة العمل (0x0000018b)" تم رفض المصادقة. |
الإجراء
توصي Microsoft بفرز سبب فشل مصادقة Kerberos ل SPN من 3 جزء. تتضمن بعض الأسباب الشائعة لفشل مصادقة Kerberos ما يلي:
-
تكون SPN المستخدمة كهدف للمصادقة مشوهة. لمزيد من المعلومات، راجع تنسيقات الاسم ل SPNs الفريدة.
ملاحظة: قد يكون للتطبيقات و واجهات برمجة التطبيقات تعريفات أكثر صرامة أو مختلفة لما يشكل SPN شرعيا لخدمتها.
أمثلة على SPN شرعي
http/webserver
Host/machine2.contoso.com
Ldap/machine1.contoso.com/contoso.com
الخدمة/الجهاز1:10100
أمثلة على SPNs التي من المحتمل أن تكون مشوهةSPN
السبب
المضيف/المضيف/الجهاز1
المضيف/المضيف هو على الغالب خطأ لأن "المضيف" عادة ما يكون فئة خدمة وليس اسم جهاز. من المحتمل أن تكون SPN الشرعية مضيفة/جهاز1.
Ldap/machine/contoso.com:10100
يمكن تحديد المنافذ على اسم المضيف ("الجهاز") وليس على اسم مثيل الخدمة. من المحتمل أن يكون SPN المشروع هو "ldap/machine:10100/contoso.com"
Ldap/dc-a/DC=CONTOSO,DC=COM
تتوقع بعض واجهات برمجة التطبيقات اسم DNS بدلا من FQDN. على سبيل المثال، تتوقع الدالة DsBindA (ntdsapi.h) أن يتم تمريرها في اسم DNS. إذا تم تمرير FQDN، فقد يؤدي ذلك إلى SPN المشوه.
قد يكون SPN المشروع "ldap/dc-a/contoso.com"لمعالجة هذه المشاكل، يجب عليك إما استخدام SPN الصحيح أو تسجيل SPN المشوه إلى حساب الخدمة الصحيح.
-
SPN الذي يتم استخدامه كهدف للمصادقة غير موجود. لمعالجة هذه المشكلة، فكر في تسجيل SPN إلى حساب الخدمة الصحيح.
-
لا Windows جهاز عميل "خط الرؤية" إلى وحدة تحكم المجال (مثل أجهزة الكمبيوتر غير المتصلة، ولا يمكن اكتشافها في DNS، أو يتم حظر الوصول إلى منفذ KDC).
-
قد تستخدم أسماء NetBIOS في سيناريو لا تعمل فيه أسماء NetBIOS. مثال على ذلك هو الوصول إلى موارد المجال من جهاز غير منضم إلى مجال، وقد تم تعطيل دقة اسم NetBIOS أو لا يعمل.
توصي Microsoft باستخدام اسم المستخدم الأساسي (UPN) أو نظام اسم المجال (DNS) الاسم بدلا من اسم NetBIOS.
تسجيل SPNs
استنادا إلى تكوين التطبيق والبيئة، قد يتم تكوين SPNs على السمة اسم الخدمة الأساسي لحساب الخدمة أو حساب الكمبيوتر الموجود في مجال Active Directory الذي يحاول عميل Kerberos إنشاء اتصال Kerberos به. لكي تعمل مصادقة Kerberos بشكل صحيح، يجب أن تكون SPN الهدف صالحة.
راجع وثائق النشر أو موفر الدعم لكل تطبيق معين للحصول على إرشادات حول كيفية تمكين مصادقة Kerberos. تقوم بعض مثبتات التطبيقات أو التطبيقات بتسجيل SPNs تلقائيا. هناك خيارات مختلفة لكل من المطورين والمسؤولين لتسجيل SPN:
-
لتسجيل SPNs يدويا لمثيل خدمة، راجع Setspn.
-
لتسجيل SPNs برمجيا لمثيل خدمة، راجع كيف تسجل الخدمة SPNs الخاصة بها تصف كيفية:
-
قم باستدعاء الدالة DsGetSpn لإنشاء واحد أو أكثر من SPN فريد لمثيل الخدمة. لمزيد من المعلومات، راجع تنسيقات الاسم ل SPNs الفريدة.
-
قم باستدعاء الدالة DsWriteAccountSpn لتسجيل الأسماء على حساب تسجيل الوصول الخاص بالخدمة.
-
المشاكل المعروفة
حاليا، لا توجد أي مشاكل معروفة في هذا التحديث.
