Ошибка входа для пользователя 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
.
![enter image description here]()
Ответ 14
У меня была такая же проблема ранее, удалив Persist Security Info=True
из строки подключения для меня.
Ответ 15
Я потратил несколько часов, пытаясь исправить проблему, и, наконец, получил ее - браузер SQL Server был "остановлен". Исправление состоит в том, чтобы изменить его на "Автоматический" режим:
Если он отключен, перейдите в Панель управления- > Административный Инструменты- > Службы и найдите агента SQL Server. Щелкните правой кнопкой мыши и выберите "Свойства". Из раскрывающегося списка "Тип запуска" измените "Отключено" до "Автоматически".
цитата отсюда
Ответ 16
Я столкнулся с этой проблемой, когда клиент переименовал SQL Server. Служба отчетов SQL была настроена для подключения к старому имени сервера, для которого также был создан псевдоним, перенаправленный на IP-адрес нового имени сервера.
Все их старые приложения IIS работали, перенаправляя на новое имя сервера через псевдоним. Я догадался, работают ли они SSRS. Попытка подключиться к сайту SSRS Вышла ошибка:
"Служба недоступна. Обратитесь к системному администратору для решения проблемы. Системные администраторы: сервер отчетов не может подключиться к своей базе данных. Убедитесь, что база данных работает и доступна. Вы также можете проверить подробности в журнале трассировки сервера отчетов".
Он работал на сервере, но не смог подключиться, поскольку использовал псевдоним для старого имени сервера. Переконфигурирование SSRS для использования нового имени сервера вместо старого/псевдонима исправило его.
Ответ 17
- Измените удостоверение пула приложений на локальную систему
- На SQL Mgmt> Безопасность> Логины
- Найти NT AUTHORITY\SYSTEM двойной щелчок
- Отображения пользователей> Проверьте свою базу данных и назначьте ей роль ниже.
- Не забудьте также создать базу данных пользователей o логины безопасности с правильным паролем.
Ответ 18
Я получил эту ошибку, пытаясь проверить решение, используя следующую
string cn = "Data Source=[servername];Integrated Security=true;Initial Catalog=[dbname];";
Я решил так: мне пришлось открыть Visual Studio и запустить его под другой учетной записью, потому что учетная запись, которую я использовал для открытия, не была моей учетной записью администратора.
Так что если ваша проблема похожа на мою: прикрепите VS к панели задач, затем используйте Shift и правый клик, чтобы открыть меню, чтобы вы могли открыть VS как другого пользователя. ![enter image description here]()
Ответ 19
Примите во внимание, что здесь есть несколько хороших ответов, но так как я только что потерял время на разработку этого, надеюсь, это может кому-то помочь.
В моем случае все работало нормально, а затем прекратилось без видимой причины с ошибкой, указанной в вопросе.
IIS работал как Сетевая служба, а Сетевая служба была настроена на SQL Server ранее (см. Другие ответы на этот пост).
Проблема была; абсолютно без видимой причины; Сетевой сервис переключился на "Запретить" права на вход в базу данных.
Фикс:
- Откройте SSMS> Безопасность> Логины.
- Щелкните правой кнопкой мыши "NT AUTHORITY\NETWORK SERVICE" и выберите "Свойства".
- Перейдите на вкладку "Статус" и установите для параметра "Разрешение" компонент Database Engine на "Предоставить".
![Network Service Allowed]()
Это позволило всем работать, и не требовалось, чтобы сетевая служба давала какие-либо дополнительные сопоставления User Mappings
как указано в другом ответе (который я поддержал для некоторых хороших указателей).
Ответ 20
Примите во внимание, что здесь есть несколько хороших ответов, но так как я только что потерял время на разработку этого, надеюсь, это может кому-то помочь.
В моем случае все работало нормально, а затем прекратилось без видимой причины с ошибкой, указанной в вопросе.
IIS работал как Сетевая служба, а Сетевая служба была настроена на SQL Server ранее (см. Другие ответы на этот пост). Роли сервера и сопоставления пользователей выглядели правильно.
Проблема была; абсолютно без видимой причины; Сетевой сервис переключился на "Запретить" права на вход в базу данных.
Фикс:
- Откройте SSMS> Безопасность> Логины.
- Щелкните правой кнопкой мыши "NT AUTHORITY\NETWORK SERVICE" и выберите "Свойства".
- Перейдите на вкладку "Статус" и установите для "
Permission to Connect To Database Engine
"Предоставить".
![Network Service Allowed]()