كيف أقوم بتكوين المصادقة بين الخوادم المرتبطة؟

Question

أحاول اختبار إثبات المفهوم الذي يمكنني من خلاله تشغيل معاملة موزعة عبر خادمي SQL مرتبطين، مرتبطين باستخدام sp_addlinkedserver - أسمائهما Server1 وServer2، وكلاهما يعمل ضمن المثيلات الافتراضية.يحتفظ كل خادم بقاعدة بيانات واحدة، المصدر والوجهة على التوالي، وقاعدة البيانات الوجهة تحتوي على جدول واحد يسمى الإخراج، أي.

Server1.Source
Server2.Destination.Output

يحتوي جدول OUTPUT على البنية التالية:

OUT_PKEY int identity(1,1) primary key,
OUT_TEXT nvarchar(255)

لقد اتصلت من Server1 sp_addlinkedserver "الخادم2" لربط قاعدتي البيانات وحاولت تشغيل الاستعلام التالي لاختبار أن الرابط يعمل بالفعل:

Select   *
From     Server2.Destination.dbo.Output

لقد تم إرجاع الاستثناء التالي:

تم رفض الوصول إلى الخادم البعيد بسبب عدم وجود تعيين لتسجيل الدخول.

عادل بما فيه الكفاية، لذلك من Server1، أركض sp_addlinkedsrvlogin "الخادم2" والتي تقول وفقًا للوثائق أنه يجب أن تأخذ بيانات اعتماد المستخدم لمن يقوم بتشغيل الاستعلام عن بعد (أيمن Server1) وقم بتطبيق بيانات الاعتماد هذه على Server2.وهذا يعني أنه بما أنني متصل بـ Server1 باستخدام مصادقة Windows، فهذا يعني أن بيانات اعتماد Windows الخاصة بي يتم تطبيقها على Server2 أيضًا.

الآن تتغير رسالة الاستثناء إلى:

فشل تسجيل الدخول للمستخدم 'NT AUTHORITY\ANONYMOUS LOGON'.

بعد أن بحثت في جوجل عن هذا الاستثناء، لم أتوصل إلى أي شيء مفيد يوجهني في الاتجاه الصحيح.ماذا ينقصني؟أتوقع [في حالة فشل تسجيل الدخول على الإطلاق] أن يتم الإشارة إلى الاستثناء لي بيانات اعتماد ويندوز، لا بيانات اعتماد تسجيل الدخول المجهول.

يبدو أنه بمجرد تشغيل الرابط نفسه، يجب أن تكون المعاملات الموزعة نفسها أمرًا بسيطًا إلى حد ما - تشير الوثائق إلى أنني بحاجة فقط إلى التأكد من تشغيل خدمة DTC على Server1 وتشغيل أي استعلامات على Server1 التي سيتم التعامل معها عبر الرابط:

• يشمل قم بضبط XACT_ABORT على التشغيل قبل تهيئة معاملتي الموزعة
• أنا أستعمل ابدأ المعاملة الموزعة بدلاً من ابدأ المعاملة
• إذا كنت أرغب في الإشارة إلى مثيل غير افتراضي لـ SQL Server على Server2، فأنا أقوم باستبدال أي مثيلات للاسم الخادم2 في استفساري مع [Server2\InstanceName]

أسئلتي هي التالية:

• كيف يمكنني تجاوز مشكلة تسجيل الدخول هذه؟ال sp_addlinkedsrvlogin لا يبدو أن الإجراء المخزن وحده يقوم بالمهمة.
• هل من السهل حقًا تشغيل المعاملة الموزعة كما تشير الوثائق؟

تيا

Answer 1

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

بافتراض أنك تقوم بتشغيل خدمات SQL على كلا الخادمين كمستخدم مجال (وهو ما ستحتاج إليه لإنجاز هذا العمل - لن يقوم LocalSystem بذلك)، فإليك الإرشادات التي ستحتاج إليها:

http://technet.microsoft.com/en-us/library/bb735885.aspx

تذكر أن المستخدم سيحتاج إلى SPN لكلا الخادمين، ولكن ليس العميل - على سبيل المثال، إذا كنت تنتقل من العميل -> الخادم 1 -> الخادم 2، فسيحتاج حساب خدمة SQL إلى SPN لكل من الخادم 1 والخادم 2.

إذا كنت محتارًا (إنها عملية مربكة)، قم بنشر تعليق وسأقوم بتوضيح التعليمات.

Answer 2

بافتراض أن هذين الخادمين موجودان في نفس المجال - هل قمت بتمكين التفويض الموثوق للسماح لخادمك بتمرير بيانات الاعتماد إلى الخادم المستهدف؟يمكنك سحب كائن Active Directory للخادم والانتقال إلى علامة التبويب "التفويض" وتحديد "الوثوق بهذا الكمبيوتر للتفويض إلى خدمات محددة فقط" ثم إدخال تفاصيل SQL Server التي يُسمح للخادم بتمرير بيانات الاعتماد إليها:

نوع الخدمة = MSSQLSvc
المستخدم/الكمبيوتر = YourTargetServer.Your.Domain
المنفذ = 1433

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

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