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

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

Используемые ящики:

Web Box
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$'.

Ссылаясь на это Ошибка «Не удалось войти в систему для пользователя 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? Но это то, что мне говорит одна ссылка, чтобы решить эту проблему.

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

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

Типичным примером может служить приложение ASP, работающее в пуле приложений, настроенном на использование учетных данных СЕТЕВОЙ СЛУЖБЫ и подключение к удаленному серверу SQL: пул приложений будет проходить проверку подлинности как компьютер, на котором запущен пул приложений, и является ли эта учетная запись компьютера, которой необходимо предоставить доступ ,

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

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

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

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

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

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

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

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

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

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

Шаг:

1. Щелкните Пулы приложений

2. Выберите название вашего приложения

3. Перейти к расширенным настройкам

4. Разверните Модель процесса и щелкните Удостоверение . Щелкните три точки на правом конце.
5. Нажмите кнопку Установить ... и укажите учетные данные для входа в домен.

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

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

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

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

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

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

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

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

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

Настройки могут быть выполнены в Internet Information Server (IIS 7+)> Application Pools> Advanded Settings> Process Model> Identity.

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

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

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

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

User Instance=true

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

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

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

В моем случае решением было настроить его «Режим аутентификации сервера», чтобы разрешить аутентификацию SQL Server, в Management Studio: Свойства / Безопасность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исправить:

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

Добавление нового ответа здесь, потому что предыдущие ответы не объясняли мою проблему. Проблема в том, что имя пользователя, требуемое в SQL, - это ИМЯ пула приложений, а не его идентификатор. .

Я запускал IIS с AppPools, установленным для ApplicationPoolIdentityидентификации.

Вызывается мое имя пользователя безопасности SQL с доступом, IIS APPPOOL\DefaultAppPoolи оно отлично работает с .NET-приложением ASP.NET Full Framework.

При запуске моего приложения ASP.NET Core он создал новый пул приложений с именем приложения, но без версии CLR и по-прежнему с тем же ApplicationPoolIdentityидентификатором.

Но посмотрев на имя пользователя, используемое через System.Security.Principal.WindowsIdentity.GetCurrent().Name, я понял, что он использует не DefaultAppPool, а новое имя пула приложений. Поэтому мне пришлось добавить нового пользователя с именем IIS APPPOOL\ApplicationNameна вкладке безопасности SQL, а не пользователя по умолчанию.