سؤال

نحن نواجه صعوبة في معرفة كيفية عمل كائنات بيانات الاعتماد هذه.في الواقع، قد لا يعملون كما توقعنا منهم أن يعملوا.وهنا شرح للمشكلة الحالية.

لدينا خادمان يحتاجان إلى التحدث مع بعضهما البعض من خلال خدمات الويب.الأول (دعنا نسميها Server01) لديه خدمة Windows تعمل كحساب NetworkService.الآخر Server02 لديه ReportingServices يعمل مع IIS 6.0.خدمة ويندوز على Server01 يحاول استخدام Server02 ReportingServices WebService لإنشاء التقارير وإرسالها عبر البريد الإلكتروني.

لذا، إليك ما جربناه حتى الآن.

تعيين بيانات الاعتماد في وقت التشغيل (هذا يعمل بشكل جيد تماما):

 rs.Credentials = new NetworkCredentials("user", "pass", "domain");

الآن، إذا تمكنا من استخدام مستخدم عام، فسيكون كل شيء على ما يرام، ولكن...لا يسمح لنا بذلك.لذلك، نحن نحاول استخدام DefaultCredetials أو DefaultNetworkCredentials وتمريرها إلى RS Webservice:

rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials

أو:

rs.Credentials = System.Net.CredentialCache.DefaultCredentials

في كلتا الحالتين لن ينجح.نحن دائمًا نتلقى 401 غير مصرح به من IIS.الآن، ما نعرفه هو أننا إذا أردنا منح حق الوصول إلى مورد تم تسجيله باسم NetworkService، فنحن بحاجة إلى منحه DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):

منح الوصول إلى خادم SQL البعيد

إذا كنت تقوم بالوصول إلى قاعدة بيانات على خادم آخر في نفس المجال (أو في مجال موثوق به)، فسيتم استخدام بيانات اعتماد الشبكة الخاصة بحساب خدمة الشبكة للمصادقة على قاعدة البيانات.تكون بيانات اعتماد حساب خدمة الشبكة على شكل DomainName\AspNetServer$، حيث DomainName هو مجال خادم ASP.NET وAspNetServer هو اسم خادم الويب الخاص بك.

على سبيل المثال، إذا كان تطبيق ASP.NET الخاص بك يعمل على خادم يُسمى SVR1 في المجال CONTOSO، فسيرى خادم SQL طلب وصول إلى قاعدة البيانات من CONTOSO\SVR1$.

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

لذا، إليك بعض الأسئلة:

  1. لقد قرأنا عن "انتحال هوية المستخدمين" في مكان ما، فهل نحتاج إلى تعيين هذا في مكان ما في ملف خدمة ويندوز ?

  2. هل من الممكن منح حق الوصول إلى حساب NetworkService المدمج لخادم IIS بعيد؟

شكرا للقراءة!

هل كانت مفيدة؟

المحلول

جميع التفاصيل التي تحتاجها موجودة في هذه المقالة القديمة جدًا،

http://msdn.microsoft.com/en-us/library/ms998351.aspx

باختصار، عندما تجد أنه من المربك استكشاف مشكلات مثل هذه وإصلاحها، يجب عليك أولاً مراجعة التفاصيل الفنية وراء انتحال صفة ASP.NET بعناية.

نصائح أخرى

إليك بعض الأشياء التي يمكنك التحقق منها:- تعيين SPN (الاسم الرئيسي للخدمة) لخدمة التقارير؛يمكنك العثور على أمثلة جيدة في جوجل؛- السماح بالتفويض (ClientCredentials.Windows.AllowImpersonationLevel)

هل المشكلة هي أنك تفشل في المصادقة على IIS، أو تفشل في المصادقة على SSRS؟قد يحتاج حساب DOMAIN\MachineName$ إلى الحصول على إذن في SSRS لتشغيل التقرير الذي تحاول تشغيله تلقائيًا.

عادةً ما يقوم SSRS بعمل جيد جدًا في تكوين IIS بشكل صحيح، لذلك لن تحتاج إلى العبث بهذه الإعدادات.لقد قمت بالتحقق مرة أخرى من التثبيت الخاص بي (وهو SSRS 2005، ربما عملت الأمور بشكل مختلف في SSRS 2000 ولم تذكر الإصدار الذي تقوم بتشغيله)، وتم ضبطه على استخدام مصادقة Windows وتم تمكين انتحال الهوية.وهذا يعني أن IIS يجب أن يقوم بشكل أساسي بمصادقة بيانات الاعتماد الخاصة بك (التحقق من صحة اسم المستخدم/كلمة المرور الصحيحة)، وليس التفويض (تحديد ما إذا كان هذا المستخدم لديه إذن لتشغيل التقرير المعني).يقوم IIS بعد ذلك بتمرير بيانات الاعتماد إلى SSRS، الذي لديه إعداداته الخاصة لتحديد الحسابات التي لديها إذن لعرض التقارير.

يمكنك أيضًا أتمتة إرسال التقارير على أساس مجدول مباشرةً في SSRS، لذلك قد لا تحتاج إلى خدمة Windows على الإطلاق إذا كانت جدولتك أساسية إلى حد ما (أي يوميًا أو أسبوعيًا وما إلى ذلك).

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top