Ошибка входа для пользователя DOMAIN\MACHINENAME $'

Я знаю, что это почти дубликат: Ошибка "Ошибка входа для пользователя" NT AUTHORITY\IUSR "" в ASP.NET и SQL Server 2008 и Ошибка входа для пользователя "имя пользователя" - System.Data.SqlClient.SqlException с LINQ в внешняя библиотека проекта/класса, но некоторые вещи не складываются по сравнению с другими приложениями на моем сервере, и я не уверен почему.

Используемые коробки:

Веб-коробка
SQL Box
SQL Test Box

Мое выражение:

У меня есть веб-приложение ASP.NET, которое ссылается на библиотеку классов, которая использует LINQ-to-SQL. Строка подключения настроена правильно в библиотеке классов. В случае сбоя входа в систему для пользователя 'username' - 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$'.

Теперь ссылаемся на это . Ошибка "Вход не выполнен для пользователя NT AUTHORITY\IUSR" в ASP.NET и SQL Server 2008 говорит о том, что действительно локальная сетевая служба и использование любого другого не доменного имени не будут работать.

Но я запутался, потому что я проверил и SQL Box, и SQL Test Box SQL Management Studio, и оба имеют NT AUTHORITY/NETWORK SERVICE разделе Безопасность → Вход в систему, на уровне базы данных, которого нет в списке Безопасность → Пользователи, но на уровне базы данных Безопасность → Пользователи У меня есть пользователь, отображаемый в строке подключения.

На уровне NTFS на веб-сервере права доступа NETWORK SERVICE имеют полный контроль.

Причина, по которой я запутался, заключается в том, что на моем веб-сервере есть много других веб-приложений, которые ссылаются на базы данных SQL Box и SQL Test Box, и все они работают. Но я не могу найти разницу между ними и моим текущим приложением, кроме того, что я использую библиотеку классов. Будет ли это иметь значение? Проверка разрешений NTFS, настройка входов в систему безопасности на уровне сервера и баз данных, строка подключения и метод подключения (учетные данные SQL Server), а также пул приложений IIS и другие параметры папок - все это одно и то же.

Почему эти приложения работают без добавления имени машины $ к разрешениям любого из моих блоков SQL? Но это то, что одна ссылка говорит мне сделать, чтобы решить эту проблему.

Ответ 1

NETWORK SERVICE и LocalSystem будут аутентифицироваться всегда как локальная корреспондирующая учетная запись (встроенная служба сети и встроенная система), но оба будут аутентифицироваться как удаленная учетная запись компьютера.

Если вы видите сбой, например Login failed for user 'DOMAIN\MACHINENAME$', это означает, что процесс, выполняющий службу NETWORK SERVICE или как LocalSystem, обратился к удаленному ресурсу, аутентифицировал себя как учетную запись компьютера и был лишен авторизации.

Типичным примером может быть приложение ASP, запущенное в пуле приложений, настроенном на использование учетных данных NETWORK SERVICE и подключение к удаленному SQL Server: пул приложений будет аутентифицироваться как машина, использующая пул приложений, и является ли эта учетная запись машины, которая должна получить доступ.

Когда доступ запрещен учетной записи компьютера, доступ к учетной записи компьютера должен быть предоставлен. Если сервер отказывается от входа в систему DOMAIN\MACHINE $, вы должны предоставить права входа в домен DOMAIN\MACHINE $не в службу NETWORK SERVICE. Предоставление доступа к службе NETWORK SERVICE позволит локальному процессу работать как NETWORK SERVICE для подключения, а не к удаленному, поскольку удаленный будет аутентифицироваться, как вы предполагали, DOMAIN\MACHINE $.

Если вы ожидаете, что приложение asp будет подключаться к удаленному SQL Server в качестве входа в систему SQL, и вы получите исключения из DOMAIN\MACHINE $, это означает, что вы используете Integrated Security в строке подключения. Если это неожиданно, это означает, что вы испортили строки подключения, которые вы используете.

Ответ 2

Эта ошибка возникает, когда вы настроили приложение в IIS, а IIS отправляется на SQL Server и пытается войти в систему с учетными данными, которые не имеют соответствующих разрешений. Эта ошибка также может возникать при настройке репликации или зеркалирования. Я буду решать решение, которое работает всегда и очень просто. Перейдите в раздел SQL Server → Безопасность → Логины и щелкните правой кнопкой мыши службу NT AUTHORITY\NETWORK SERVICE и выберите Свойства

Во вновь открывшемся экране Свойства входа перейдите на вкладку "Сопоставление пользователей". Затем на вкладке "Сопоставление пользователей" выберите нужную базу данных - особенно базу данных, для которой отображается это сообщение об ошибке. На нижнем экране проверьте роль db_owner. Нажмите "ОК".

Ответ 3

В моем случае у меня был Identity="ApplicationPoolIdentity" для моего пула приложений IIS.

После добавления пользователя IIS APPPOOL\ApplicationName на SQL Server он работает.

Ответ 4

Трюк, который сработал у меня, заключался в удалении Integrated Security из моей строки подключения и добавлении регулярной User ID=userName; Password=password вашей строки подключения в App.config вашего libral, возможно, не было использования встроенной безопасности, а созданной в Web.config is!

Ответ 5

У коллеги была такая же ошибка, и это было связано с небольшой ошибкой конфигурации в IIS.
Для веб-приложения был назначен неправильный пул приложений.

В действительности мы используем собственный пул приложений с определенным идентификатором для удовлетворения наших потребностей.

В своем локальном диспетчере IIS → Сайты → Веб-сайт по умолчанию → Имя нашего веб-приложения → Основные настройки... Пул приложений был "DefaultAppPool" вместо нашего настраиваемого пула приложений.

Настройка правильного пула приложений решила проблему.

Ответ 6

Я добавил <identity impersonate="true" /> в свой web.config, и он отлично работал.

Ответ 7

В основном, чтобы решить эту проблему, нам нужно настроить

Веб-приложение, работающее под ApplicationPoolIdentity
Веб-приложение, подключающееся к базам данных через ADO.Net с использованием проверки подлинности Windows в строке подключения

Строка подключения, используемая при аутентификации Windows, включает в себя либо атрибут Trusted_Connection=Yes либо эквивалентный атрибут Integrated Security=SSPI в файле Web.config

Мое соединение с базой данных находится в режиме аутентификации Windows. Поэтому я решил эту проблему, просто изменив Идентификацию пулов приложений с ApplicationPoolIdentity на журнал моего домена с учетными данными DomainName\MyloginId

Шаг:

Нажмите на пулы приложений
Выберите название вашей заявки
Перейти к расширенным настройкам
Разверните Модель процесса и нажмите Идентификация. Нажмите три точки на правом конце.
Нажмите кнопку Установить... и введите учетные данные для входа в домен.

Для меня это было решено.

Примечание. В производственной или ИТ-среде у вас может быть учетная запись службы в одном домене для идентификации пула приложений. Если это так, используйте учетную запись службы вместо вашего логина.

Ответ 8

Для меня проблема была решена, когда я заменил встроенную по умолчанию учетную запись "ApplicationPoolIdentity" с сетевой учетной записью, которой был разрешен доступ к базе данных.

Настройки могут быть сделаны в Internet Information Server (IIS 7+) > Пулы приложений > Расширенные настройки > Модель процессa > Идентификация

Ответ 9

Мы получали похожие сообщения об ошибках при обработке базы данных служб Analysis Services. Оказалось, что имя пользователя, которое использовалось для запуска экземпляра служб Analysis Services, не было добавлено в логины безопасности SQL Server.

В SQL Server 2012 службы SQL Server и Analysis настроены для работы по-разному по умолчанию. Если вы пошли по умолчанию, всегда убедитесь, что пользователь AS имеет доступ к вашему источнику данных!

Ответ 10

Проверьте, есть ли у вас

User Instance=true

в строке подключения. Попробуйте удалить его, чтобы решить вашу проблему.

Ответ 11

У меня также была эта ошибка с аутентифицированным пользователем SQL Server

Я испробовал некоторые исправления, но они не работали.

Решение в моем случае состояло в том, чтобы настроить "Режим аутентификации сервера", чтобы разрешить аутентификацию SQL Server в разделе "Управление Studio: Свойства/Безопасность".

Ответ 12

Единственный момент, который, по-видимому, игнорируют все, заключается в том, что вам может потребоваться интегрированная безопасность = true. Возможно, сайт работает под учетной записью пула. Это все так хорошо, и все равно можно поразить SQL-сервер исходными учетными данными пользователя, а не пулом. Он назывался ограниченным делегированием. Если вы включите его и настройте окна SPN, вы переводите учетные данные пула с пользователем по запросам, отправляющимся на конечную службу (SQL - это всего лишь одна такая служба). Вы должны зарегистрировать ОДИН И ТОЛЬКО SQL-сервер, который обслуживает запросы SQL на веб-сервере. Для меня это слишком сложно, чтобы попытаться точно описать здесь. Мне потребовалось немало времени, чтобы проработать это самостоятельно.

Ответ 13

Для меня проблема с 'DOMAIN\MACHINENAME $' исправлена установкой DefaultApplicationPool Identity в NetworkService.

Ответ 14

У меня была такая же проблема ранее, удалив Persist Security Info=True из строки подключения для меня.

Ответ 15

Я потратил несколько часов, пытаясь исправить проблему, и, наконец, получил ее - браузер SQL Server был "остановлен". Исправление состоит в том, чтобы изменить его на "Автоматический" режим:

Если он отключен, перейдите в Панель управления- > Административный Инструменты- > Службы и найдите агента SQL Server. Щелкните правой кнопкой мыши и выберите "Свойства". Из раскрывающегося списка "Тип запуска" измените "Отключено" до "Автоматически".

цитата отсюда

Ответ 16

Я столкнулся с этой проблемой, когда клиент переименовал SQL Server. Служба отчетов SQL была настроена для подключения к старому имени сервера, для которого также был создан псевдоним, перенаправленный на IP-адрес нового имени сервера.

Все их старые приложения IIS работали, перенаправляя на новое имя сервера через псевдоним. Я догадался, работают ли они SSRS. Попытка подключиться к сайту SSRS Вышла ошибка:

"Служба недоступна. Обратитесь к системному администратору для решения проблемы. Системные администраторы: сервер отчетов не может подключиться к своей базе данных. Убедитесь, что база данных работает и доступна. Вы также можете проверить подробности в журнале трассировки сервера отчетов".

Он работал на сервере, но не смог подключиться, поскольку использовал псевдоним для старого имени сервера. Переконфигурирование SSRS для использования нового имени сервера вместо старого/псевдонима исправило его.

Ответ 17

Измените удостоверение пула приложений на локальную систему
На SQL Mgmt> Безопасность> Логины
1. Найти NT AUTHORITY\SYSTEM двойной щелчок
2. Отображения пользователей> Проверьте свою базу данных и назначьте ей роль ниже.
3. Не забудьте также создать базу данных пользователей o логины безопасности с правильным паролем.

Ответ 18

Я получил эту ошибку, пытаясь проверить решение, используя следующую

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

Я решил так: мне пришлось открыть Visual Studio и запустить его под другой учетной записью, потому что учетная запись, которую я использовал для открытия, не была моей учетной записью администратора.

Так что если ваша проблема похожа на мою: прикрепите VS к панели задач, затем используйте Shift и правый клик, чтобы открыть меню, чтобы вы могли открыть VS как другого пользователя.

Ответ 19

Примите во внимание, что здесь есть несколько хороших ответов, но так как я только что потерял время на разработку этого, надеюсь, это может кому-то помочь.

В моем случае все работало нормально, а затем прекратилось без видимой причины с ошибкой, указанной в вопросе.

IIS работал как Сетевая служба, а Сетевая служба была настроена на SQL Server ранее (см. Другие ответы на этот пост).

Проблема была; абсолютно без видимой причины; Сетевой сервис переключился на "Запретить" права на вход в базу данных.

Фикс:

Откройте SSMS> Безопасность> Логины.
Щелкните правой кнопкой мыши "NT AUTHORITY\NETWORK SERVICE" и выберите "Свойства".
Перейдите на вкладку "Статус" и установите для параметра "Разрешение" компонент Database Engine на "Предоставить".

Это позволило всем работать, и не требовалось, чтобы сетевая служба давала какие-либо дополнительные сопоставления User Mappings как указано в другом ответе (который я поддержал для некоторых хороших указателей).

Ответ 20

IIS работал как Сетевая служба, а Сетевая служба была настроена на SQL Server ранее (см. Другие ответы на этот пост). Роли сервера и сопоставления пользователей выглядели правильно.

Фикс:

Откройте SSMS> Безопасность> Логины.
Щелкните правой кнопкой мыши "NT AUTHORITY\NETWORK SERVICE" и выберите "Свойства".
Перейдите на вкладку "Статус" и установите для " Permission to Connect To Database Engine "Предоставить".