لماذا لا يزال SQL Server عبر VPN يعود إلى NTLM؟

اتصالك يعمل، ويُقبل تسجيل الدخول، وSQL Server يستخدم NTLM بينما كان الجميع يتوقع Kerberos. تلك النتيجة ليست عيبًا في VPN، لأن النفق يوفر مسارًا فقط؛ وقد حُدِّد المخطط بالاسم الذي طلبه العميل، والهوية الرئيسية المسجلة في الدليل، والتذكرة التي استطاع العميل الحصول عليها فعليًا. يجب أن تتحقق ثلاثة شروط في آن واحد، والجلسة نفسها تخبرك أيها تخلى. اقرأ ذلك قبل أن يعدّل أي شخص اسم الخدمة الرئيسي.

الجلسة تسمّي المخطط الذي حصلت عليه فعلًا

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

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

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

الشرط الأول: هل يطابق الاسم الـ SPN؟

يصادق Kerberos على خدمة مسمّاة، لذا يطلب العميل من الدليل تذكرة لهوية رئيسية واحدة محددة. وبالنسبة لموفر TCP، الصيغة الموثقة هي MSSQLSvc/ يتبعها اسم المضيف المؤهل بالكامل، وللنسخة الافتراضية المنفذ. وتسجّل النسخة المسماة MSSQLSvc/db01.corp.example:SQLPROD، حيث تكون اللاحقة اسم النسخة بدلًا من رقم. والوصول إلى المستمع عبر اسم مستعار، أو CNAME يُحلّ في مكان آخر، أو عنوان IP مجرد يغيّر الاسم المطلوب، والطلب الذي لا يجد هوية رئيسية مطابقة لا يملك تذكرة يعيدها.

ولهذا يعمل تطبيق على شبكة ويرتد إلى أخرى: إجابة DNS أو سجل اسم مستعار أو مدخل hosts غيّر الاسم الذي استخدمه العميل. قارن الاسم المطلوب بما يحتفظ به الدليل قبل المساس بالتسجيل.

الشرط الثاني: هل الـ SPN على الحساب الصحيح؟

يجب أن ينتمي SPN إلى الحساب الذي يشغّل خدمة SQL، لا إلى حساب العميل ولا إلى كائن حاسوب بالمصادفة. ويستطيع SQL Server تسجيل SPN الخاصة به عند بدء التشغيل حين يملك حساب خدمته إذن كتابتها، وهذا مريح وهو أيضًا كيفية ظهور نسخة مكررة بعد تغيير حساب الخدمة.

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

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

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

الشرط الثالث: هل يستطيع العميل الحصول على تذكرة أصلًا؟

لا قيمة لـ SPN صحيح إذا لم يستطع العميل الوصول إلى وحدة تحكم النطاق أو لم يكن لديه سياق بيانات اعتماد صالح للاستخدام. ويحتاج التبادل إلى KDC وDNS عبر VPN، والنفق الذي يوجّه منفذ SQL فقط يفشل في هذه الخطوة تحديدًا. ويجب اختبار إمكانية الوصول من الجهاز نفسه والحساب نفسه، لا من الجدار الناري الذي أمامهما.

افحص ذاكرة التذكرة المؤقتة على الجهاز وتحت الحساب الذي يشغّل التطبيق. فقائمة على مستوى الجهاز من نافذة مرتفعة الصلاحيات لا تقول شيئًا عن خدمة تعمل بمستخدم آخر، وذاكرة فارغة لذلك المستخدم نتيجة تستحق التسجيل لا مجرد إزعاج.

klist
klist -li 0x3e7

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

تغيير المشغّل متغير واحد، وليس حلًا

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

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

عندما يُشترط Kerberos، سجّل سبب ارتداد المسار الأول، وطبّق تصحيحًا واحدًا، وأعد تنفيذ الاستعلام من العميل نفسه. فالاستعلام الناجح بعد تغيير المشغّل دليل على الوصول، وليس بعد دليلًا على أن متطلب المصادقة قد تحقق.