فشل تسجيل الدخول لـ User 'Domain machinename $'

Question

أعلم أن هذا تقريبًا مكرر من: الخطأ "فشل تسجيل الدخول بالنسبة للسلطة المستخدم iusr" في ASP.NET و SQL Server 2008 و فشل تسجيل الدخول للمستخدم "اسم المستخدم" - System.data.sqlclient.sqlexception مع LINQ في مكتبة المشروع / الفئة الخارجي لكن بعض الأشياء لا تضيف ما يصل مقارنة بالأجهزة الأخرى على الخادم الخاص بي ولست متأكدًا من السبب.

يتم استخدام الصناديق:

مربع الويب
SQL Box
مربع اختبار SQL

طلبي:

لدي تطبيق ويب ASP.NET ، والذي يشير إلى مكتبة فئة تستخدم LINQ-to-SQL. تم إعداد سلسلة الاتصال بشكل صحيح في مكتبة الفصل. حسب فشل تسجيل الدخول للمستخدم "اسم المستخدم" - System.data.sqlclient.sqlexception مع LINQ في مكتبة المشروع / الفئة الخارجي أضفت أيضًا سلسلة الاتصال هذه إلى تطبيق الويب.

تستخدم سلسلة الاتصال بيانات اعتماد SQL على النحو (في كل من تطبيق الويب ومكتبة الفصل):

 <add name="Namespace.My.MySettings.ConnectionStringProduction"
        connectionString="Data Source=(SQL Test Box);Initial Catalog=(db name);Persist Security Info=True;User ID=ID;Password=Password"
        providerName="System.Data.SqlClient" />

أكد هذا الاتصال على أنه يعمل من خلال إضافته إلى مستكشف الخادم. هذه هي سلسلة الاتصال التي يستخدمها ملف .DBML.

المشكلة:

أحصل على الخطأ التالية:

System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.

الآن الرجوع إلى هذا الخطأ "فشل تسجيل الدخول بالنسبة للسلطة المستخدم iusr" في ASP.NET و SQL Server 2008 تقول أن هذه خدمة الشبكة المحلية واستخدام أي اسم غير آخر غير آخر لن يعمل.

لكنني مرتبك لأنني راجعت كل من SQL Box و SQL Box Box SQL Management Studio وكلاهما NT AUTHORITY/NETWORK SERVICE ضمن الأمان -> تسجيل الدخول ، على مستوى قاعدة البيانات ، غير مدرج ضمن الأمان -> المستخدمين ، ولكن في أمان مستوى قاعدة البيانات -> المستخدمون قد تم عرض المستخدم في سلسلة الاتصال.

على مستوى NTFS على خادم الويب ، تحتوي الأذونات على خدمة الشبكة تحكم كامل.

السبب في أنني في حيرة من أمري هو أن لدي العديد من تطبيقات الويب الأخرى على خادم الويب الخاص بي ، وقواعد البيانات المرجعية على كل من SQL Box و SQL Test ، وكلها تعمل. لكن لا يمكنني العثور على فرق بينهما وبين طلبي الحالي ، بخلاف أنا أستخدم مكتبة الفصل. هل هذا مهم؟ إن التحقق من أذونات NTFS ، وإعداد تسجيلات تسجيلات الأمان على مستويات قواعد الخادم ومستويات قواعد البيانات ، وسلسلة الاتصال وطريقة الاتصال (بيانات اعتماد خادم SQL) ، ومجموعة تطبيقات IIS وخيارات المجلد الأخرى ، كلها متماثلة.

لماذا تعمل هذه التطبيقات دون إضافة اسم machinenename إلى أذونات أي من صناديق SQL الخاصة بي؟ ولكن هذا ما يخبرني به الرابط الواحد أن أفعل لإصلاح هذه المشكلة.

Answer 1

ستقوم خدمة الشبكة والحبال الصناديق بمصادقة أنفسهم دائمًا كحساب cerrepsonding محليًا (تم تصميمه خدمة الشبكة ومصنته System) ولكن كلاهما سيصادق كحساب الجهاز عن بُعد.

إذا رأيت فشلًا مثل Login failed for user 'DOMAIN\MACHINENAME$' وهذا يعني أن عملية تشغيل كخدمة شبكة أو مع وصول LolalSystem قد وصلت إلى مورد بعيد ، وقد صدقت نفسها كحساب الجهاز وتم رفض التفويض.

المثال النموذجي سيكون تطبيق ASP يعمل في مجموعة تطبيقات تطبيق لاستخدام بيانات اعتماد خدمة الشبكة والاتصال بخادم SQL عن بُعد: سيصادق تجمع التطبيق كـ آلة تشغيل تجمع التطبيقات ، وهو حساب الجهاز الذي يحتاج إلى منح الوصول.

عند رفض الوصول إلى حساب الجهاز ، يجب منح الوصول إلى حساب الجهاز. إذا رفض الخادم تسجيل الدخول "المجال machine $" ، فيجب عليك منح حقوق تسجيل الدخول إلى "المجال machine $" ليس لخدمة الشبكة. سيسمح منح الوصول إلى خدمة الشبكة محلي قم بتشغيل الخدمة كخدمة شبكة للاتصال ، وليس بعيدة ، لأن جهاز التحكم عن بُعد سيصادقه ، كما تظن ، المجال machine $.

إذا كنت تتوقع أن يتصل تطبيق ASP بخادم SQL عن بُعد كتسجيل دخول SQL وستحصل على استثناءات حول المجال $ فهذا يعني أنك تستخدم أمان متكامل في سلسلة الاتصال. إذا كان هذا غير متوقع ، فهذا يعني أنك وضعت سلاسل الاتصال التي تستخدمها.

Answer 2

يحدث هذا الخطأ عندما تقوم بتكوين التطبيق الخاص بك باستخدام IIS ، ويذهب IIS إلى SQL Server ويحاول تسجيل الدخول باستخدام بيانات الاعتماد التي لا تحتوي على أذونات مناسبة. يمكن أن يحدث هذا الخطأ أيضًا عند إعداد النسخ المتماثل أو النسخ المتطابق. سأذهب إلى حل يعمل دائمًا وهو بسيط للغاية. انتقل إلى SQL Server >> Security >> تسجيل الدخول والنقر بزر الماوس الأيمن على NT Authority Network Service وحدد الخصائص

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

Answer 3

في حالتي كان لدي Identity="ApplicationPoolIdentity" لمجموعة تطبيقات IIS الخاصة بي.

بعد أن أضفت IIS APPPOOL\ApplicationName المستخدم إلى خادم SQL يعمل.

Answer 4

كان لدى الزميل نفس الخطأ وكان بسبب خطأ تكوين صغير في IIS.
تم تعيين تجمع التطبيقات الخطأ لتطبيق الويب.

في الواقع ، نستخدم تجمع تطبيقات مخصص بهوية محددة لتلبية احتياجاتنا.

في مدير IIS المحلي -> المواقع -> موقع الويب الافتراضي -> اسم تطبيق الويب الخاص بنا -> الإعدادات الأساسية ... كان تجمع التطبيقات "DefaultAppppool" بدلاً من تجمع التطبيقات المخصص لدينا.

ضبط تجمع التطبيقات الصحيح حل المشكلة.

Answer 5

كانت الحيلة التي نجحت بالنسبة لي هي الإزالة Integrated Security من سلسلة الاتصال الخاصة بي وأضف عادية User ID=userName; Password=password سلسلة الاتصال الخاصة بك في App.config من مكتبتك قد لا تستخدم الأمان المتكامل ولكن الشخص الذي تم إنشاؤه في Web.config هو!

Answer 6

أضفت <identity impersonate="true" /> إلى web.config وعملت بشكل جيد.

Answer 7

في الأساس لحل هذا ، نحتاج إلى إعداد بعض مثل

• تطبيق الويب يعمل ضمن ApplicationPoolidentity
• تطبيق الويب الذي يتواصل مع قواعد البيانات من خلال ado.net باستخدام مصادقة Windows في سلسلة الاتصال

تتضمن سلسلة الاتصال المستخدمة مع مصادقة Windows أيضًا Trusted_Connection=Yesالسمة أو السمة المكافئة Integrated Security=SSPI في Web.config ملف

اتصال قاعدة البيانات الخاص بي في وضع مصادقة Windows. لذلك قمت بحلها بمجرد تغيير تجمعات التطبيقات الهوية من ApplicationPoolidentity إلى سجل المجال الخاص بي في بيانات الاعتماد المجال myloginid

خطوة:

1. انقر فوق تجمعات التطبيقات

2. حدد اسم التطبيق الخاص بك

3. اذهب إلى إعدادات متقدمة

4. وسعت نموذج عملية وانقر هوية. انقر فوق ثلاثة نقطة في النهاية اليمنى.
5. انقر جلس... الزر وتوفير سجل المجال الخاص بك في بيانات الاعتماد

بالنسبة لي تم حلها.

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

Answer 8

بالنسبة لي تم حل المشكلة عندما استبدلت الحساب المدمج الافتراضي "ApplicationPoolidentity" بحساب شبكة سمح بالوصول إلى قاعدة البيانات.

يمكن إجراء الإعدادات في خادم معلومات الإنترنت (IIS 7+)> تجمعات التطبيقات> الإعدادات المقدمة> نموذج المعالجة> الهوية

Answer 9

بالنسبة لي مشكلة مع "Domain machinename $" عن طريق الإعداد DefaultApplicationPool الهوية ل NetworkService.

Answer 10

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

في SQL Server 2012 ، يتم تكوين خدمات SQL Server و Service لتشغيلها كمستخدمين مختلفين بشكل افتراضي. إذا كنت قد ذهبت مع الإعدادات الافتراضية ، فتأكد دائمًا من أن المستخدم يمكنه الوصول إلى مصدر البيانات الخاص بك!

Answer 11

تحقق إذا كان لديك

User Instance=true

في سلسلة الاتصال. حاول إزالتها التي ستحل مشكلتك.

Answer 12

كما كان لدي هذا الخطأ مع مستخدم مصادق على خادم SQL

جربت بعض الإصلاحات ، لكنهم لم ينجحوا.

كان الحل في حالتي هو تكوين "وضع مصادقة الخادم" للسماح بمصادقة خادم SQL ، ضمن استوديو الإدارة: الخصائص/الأمان.

Answer 13

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

Answer 14

قضيت بضع ساعات في محاولة لإصلاح المشكلة وأخيراً حصلت عليها - تم "إيقاف" متصفح SQL Server. الإصلاح هو تغييره إلى وضع "تلقائي":

إذا تم تعطيله ، فانتقل إلى لوحة التحكم-> الأدوات الإدارية-> الخدمات ، وابحث عن وكيل SQL Server. انقر بزر الماوس الأيمن ، وحدد "الخصائص". من القائمة المنسدلة "نوع بدء التشغيل" ، قم بالتغيير من "تعطيل" إلى "تلقائي".

اقتبس من هنا

Answer 15

كان لدي نفس المشكلة في وقت سابق ، وإزالة Persist Security Info=True من ConnectionString عملت بالنسبة لي.

Answer 16

ركضت عبر هذه المشكلة عندما قام عميل بتسمية خادم SQL. تم تكوين خدمة التقارير SQL للاتصال باسم الخادم القديم ، والتي أنشأوها أيضًا اسم مستعار لتلك التي تم إعادة توجيهها إلى IP لاسم الخادم الجديد.

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

"الخدمة غير متوفرة. اجعل مسؤول النظام الخاص بك لحل المشكلة. مسؤولو النظام: لا يمكن لخادم التقرير الاتصال بقاعدة البيانات الخاصة به. تأكد من تشغيل قاعدة البيانات ويمكن الوصول إليها. يمكنك أيضًا التحقق من سجل تتبع خادم التقرير للحصول على التفاصيل "

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

Answer 17

1. قم بتغيير هوية تجمع التطبيق إلى النظام المحلي
2. على SQL Mgmt> Security> تسجيلات تسجيل الدخول
   1. ابحث عن NT Authority System انقر نقرًا مزدوجًا
   2. تعيينات المستخدم> تحقق من قاعدة البيانات الخاصة بك ومنحها دورًا أدناه.
   3. تذكر أيضًا إنشاء قاعدة بيانات المستخدم O تسجيل الدخول إلى أمان بكلمة مرور صحيحة.

Answer 18

حصلت على هذا الخطأ في محاولة لاختبار حل باستخدام ما يلي

string cn = "Data Source=[servername];Integrated Security=true;Initial Catalog=[dbname];";

كانت الطريقة التي حللت بها هي: اضطررت إلى فتح Visual Studio وتشغيله تحت حساب آخر ، لأن الحساب الذي كنت أستخدمه لفتح لم يكن حساب المسؤول الخاص بي.

لذا ، إذا كانت مشكلتك مشابهة لمشكلتي: قم بتثبيت VS إلى شريط المهام ، فاستخدم SHIFT وانقر بزر الماوس الأيمن لفتح القائمة حتى تتمكن من فتح VS كمستخدم آخر.

Answer 19

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

في حالتي ، كان كل شيء يعمل بشكل جيد ، ثم توقف دون سبب واضح مع الخطأ المذكور في السؤال.

تم تشغيل IIS كخدمة الشبكة وتم إعداد خدمة الشبكة على SQL Server سابقًا (انظر إجابات أخرى على هذا المنشور). بدت أدوار الخادم وأدوات المستخدم صحيحة.

كانت القضية ؛ على الإطلاق لا يوجد سبب واضح ؛ تحولت خدمة الشبكة إلى "رفض" حقوق تسجيل الدخول في قاعدة البيانات.

لإصلاح:

1. افتح SSMS> Security> تسجيل الدخول.
2. انقر بزر الماوس الأيمن على "NT Authority Network Service" وانقر فوق الخصائص.
3. انتقل إلى علامة التبويب "الحالة" وتعيين Permission to Connect To Database Engine إلى "منحة".