VPN يتصل لكن SQL Server يرفض مصادقة Windows

ترتفع الأنفاق، وتستجيب الخوادم لـ ping، ومع ذلك يفشل تسجيل الدخول إلى قاعدة البيانات بخطأ مصادقة. هذه التركيبة شائعة على روابط VPN ونادرًا ما تعني أن الشبكة معطلة، لأن المستمع الذي يمكن الوصول إليه وتسجيل الدخول المقبول نتيجتان مختلفتان. الهوية التي أرضت البوابة ليست بالضرورة الهوية التي يقدمها عميل قاعدة البيانات. معرفة أي حساب وصل هي المهمة كلها.

العَرَض: خادم يمكن الوصول إليه وتسجيل دخول مرفوض

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

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

هويتان ونفق واحد

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

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

بعض عملاء الوصول البعيد الأصليين في Windows يستطيعون إعادة استخدام بيانات اعتماد VPN لموارد الشبكة عندما يكون ملفهم الشخصي مهيأً بذلك الشكل. هذا السلوك يخص عميلًا وملفًا معينين، لا اتصالات VPN عمومًا، فتحقق منه للعميل المستخدم بدلًا من افتراضه.

اقرأ الوضع الذي طلبه العميل

سلسلة الاتصال تحدد مسار المصادقة الذي يسلكه العميل. الأمان المتكامل يستخدم رمز Windows؛ أما زوج المستخدم وكلمة المرور فيختار تسجيل دخول SQL. هذان وضعان منفصلان في تهيئة الخادم، ولا يمكن تمكين إلا واحد منهما لمحاولة اتصال معينة.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

التحول إلى تسجيل دخول SQL لأن تسجيل دخول Windows فشل هو حل التفافي يخفي سؤال الهوية، ويحتاج عادةً إلى إنشاء تسجيل دخول وكلمة مرور جديدين على أي حال. إن كان النشر يتطلب مصادقة Windows فاحتفظ بالوضع وأصلح مسار الهوية. تسجيل دخول SQL يحتاج أيضًا إلى صلاحياته الخاصة، فالحل الالتفافي يشتري حسابًا ثانيًا للصيانة.

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

اسأل الخادم بما رآه فعليًا

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

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

الصف الأول يميز تسجيل الدخول الذي فتح الجلسة عن سياق الأمان الساري الآن، وهما يختلفان عند انتحال الهوية. والثاني يسمّي مخطط المصادقة، فتصبح KERBEROS و NTLM و SQL حقائق ظاهرة بدلًا من تخمينات. الاتصال الذي يبلّغ عن NTLM حيث توقعت Kerberos مشكلة في تحليل الأسماء أو في SPN، وليست مشكلة كلمة مرور.

رقم الخطأ يضيّق الاحتمال أكثر. الحالة 5 تعني عادةً أن اسم تسجيل الدخول لم يُحلَّ إطلاقًا، والحالة 8 تعني عادةً أن كلمة المرور لم تطابق، والحالة 11 تعني أن بيانات الاعتماد قُبلت لكن الوصول إلى الخادم فشل. اطلب من المسؤول الحالة بدلًا من الرسالة كاملة، فالرسالة وحدها غامضة عن قصد.

حين تصل الهوية ويظل Kerberos يفشل

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

اطلب من المسؤول مراجعة الهوية المسجلة وحساب الخدمة بدلًا من إنشاء SPN مكررة بالتجربة والخطأ. التسجيلات المكررة تنتج أعطالًا متقطعة يصعب تشخيصها أكثر من المشكلة الأصلية.

بعد نجاح المصادقة، ما زال تسجيل الدخول يحتاج إلى مستخدم قاعدة بيانات وصلاحيات. تسجيل دخول ناجح عبر VPN، وتسجيل دخول ناجح عبر Windows، وصلاحية قراءة جدول معين، ثلاث نتائج منفصلة، وكل واحدة منها تستحق فحصها قبل إغلاق التذكرة.