Ошибка входа для пользователя ' DOMAINMACHINENAME$'
Я знаю, что это почти дубликат : ошибка "Ошибка входа для пользователя' NT AUTHORITYIUSR '" в ASP.NET и SQL Server 2008 и ошибка входа для пользователя "имя пользователя" - система.Данные.SqlClient.SqlException с LINQ во внешнем проекте / библиотеке классов но некоторые вещи не складываются по сравнению с другими приложениями на моем сервере, и я не уверен, почему.
коробок используются:
Web Box
SQL Box
Тест SQL Коробка
Приложения:
у меня есть aASP.NET веб-приложение, которое ссылается на библиотеку классов, использующую LINQ-to-SQL. Строка подключения правильно настроена в библиотеке классов. Согласно ошибка входа для пользователя "имя пользователя" - система.Данные.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" />
это соединение подтверждено как работающее, добавив его в Обозреватель серверов. Это строка подключения my .dbml файл используется.
проблема:
Я получаю следующую ошибку:
System.Data.SqlClient.SqlException: Login failed for user 'DOMAINMACHINENAME$'.
Теперь ссылаясь на это ошибка "Ошибка входа для пользователя' NT AUTHORITYIUSR '" в ASP.NET и SQL Server 2008 Он говорит, что это действительно локальной сети обслуживание и использование любого другого домена имя не будет работать.
но я в замешательстве, потому что я проверил оба SQL Box и SQL Test Box SQL Management Studio и оба имеют NT AUTHORITY/NETWORK SERVICE В разделе Безопасность - > логины на уровне базы данных, который не указан в разделе Безопасность -> пользователи, но на уровне базы данных Безопасность -> пользователи у меня есть пользователь, отображаемый в строке подключения.
на уровне NTFS на веб-сервере разрешения имеют сетевой сервис имеет полный контроль.
причина, почему я в замешательстве, потому что У меня есть много других веб-приложений на моем веб-сервере, которые ссылаются на базы данных как на SQL Box, так и на SQL Test Box, и все они работают. Но я не могу найти разницу между ними и моим текущим приложением, кроме того, что я использую библиотеку классов. Будет ли это иметь значение? Проверка разрешений NTFS, настройка учетных записей безопасности на уровне сервера и баз данных, строка подключения и способ подключения (учетные данные SQL Server), а также пул приложений IIS и другие параметры папки - все это тот же.
почему эти приложения работают без добавления machinename$ к разрешениям любого из моих SQL-ящиков? Но это то, что одна ссылка говорит мне сделать, чтобы исправить эту проблему.
16 ответов:
сетевая служба " и "система будет проходить проверку подлинности всегда как на счет correpsonding локально (встроенная сетевая служба\и система\ "встроенные"), но как будут проверять подлинность как у учетной записи компьютера удаленно.
Если вы видите неудачу как
Login failed for user 'DOMAIN\MACHINENAME$'Это означает, что процесс, запущенный как сетевая служба или как локальная система, получил доступ к удаленному ресурсу, аутентифицировался как учетная запись компьютера и ему было отказано в авторизации.типичным примером будет Приложение ASP, запущенное в пуле приложений, настроенном на использование учетных данных сетевой службы и подключение к удаленному SQL Server: пул приложений будет аутентифицироваться как машина запуск пула приложений, и это учетная запись компьютера, которая должна быть предоставлена доступ.
если доступ к учетной записи компьютера запрещен, то доступ должен быть предоставлен учетной записи компьютера. Если сервер отказывается войти в систему " домен\машина$", то вы должны предоставить права входа в систему "домен\машина$" не в сеть УСЛУГА. Предоставление доступа к сетевому сервису позволит a local процесс работает как сетевая служба для подключения, а не удаленный, так как удаленный будет аутентифицироваться как, как вы догадались, домен\MACHINE$.
Если вы ожидаете, что приложение asp подключится к удаленному SQL Server в качестве имени входа SQL, и вы получите исключения о домене\MACHINE$, это означает, что вы используете встроенную безопасность в строке подключения. Если это неожиданно, это означает, что вы испортили соединение строки, которые вы используете.
эта ошибка возникает, когда вы настроили приложение с IIS, и IIS переходит на SQL Server и пытается войти с учетными данными, которые не имеют надлежащих разрешений. Эта ошибка также может возникать при настройке репликации или зеркального отображения. Я буду идти над решением, которое работает всегда и очень просто. Перейдите в SQL Server > > Security >> Logins и щелкните правой кнопкой мыши на NT AUTHORITY\NETWORK SERVICE и выберите Properties
во вновь открывшемся окне свойств входа перейдите к Вкладка "сопоставление пользователей". Затем на вкладке" сопоставление пользователей " выберите нужную базу данных – особенно базу данных, для которой отображается это сообщение об ошибке. На нижнем экране проверьте роль db_owner. нажимать OK.
у коллеги была такая же ошибка, и это было связано с небольшой ошибкой конфигурации в IIS.
Неправильный пул приложений для веб-приложения.действительно, мы используем пользовательский пул приложений с определенным идентификатором для удовлетворения наших потребностей.
в своем локальном Диспетчере IIS - > сайты - > веб-сайт по умолчанию - > имя нашего веб-приложения - > основные настройки... Пул приложений был "DefaultAppPool" вместо нашего пользовательского пула приложений.
настройка правильный пул приложений решил проблему.
в моем случае у меня было
Identity="ApplicationPoolIdentity"для моего пула приложений IIS.после того, как я добавил
IIS APPPOOL\ApplicationNameпользователь в SQL Server он работает.
трюк, который работал для меня было убрать
Integrated Securityиз моей строки подключения и добавить обычныйUser ID=userName; Password=passwordваша строка подключения вApp.configвашего libruary может не использовать интегрированную безопасность, но тот, который создан вWeb.config- это!
для меня проблема была решена, когда я заменил встроенную учетную запись по умолчанию "ApplicationPoolIdentity" сетевой учетной записью, которой был разрешен доступ к базе данных.
настройки могут быть сделаны в Internet Information Server (IIS 7+) > пулы приложений > Расширенные настройки > модель процесса > удостоверение
в основном, чтобы решить эту проблему мы должны иметь некоторый набор, как
- веб-приложение работает под ApplicationPoolIdentity
- подключение веб-приложения к базам данных через ADO.Net использование проверки подлинности Windows в строке подключения
строка подключения, используемая при проверке подлинности Windows, включает либо
Trusted_Connection=Yesатрибут или эквивалентный атрибутIntegrated Security=SSPIinWeb.configfileмое соединение с базой данных в Windows Режим проверки подлинности. Поэтому я решил это, просто изменив Пулы Приложений личность от ApplicationPoolIdentity в мой домен войти учетные данные DomainName\MyloginId
действие:
- нажать на кнопку Пулы Приложений
выберите имя приложения
на Дополнительные Настройки
- расширения
мы получали аналогичные сообщения об ошибках при обработке базы данных служб Analysis Services. Оказалось, что имя пользователя, которое использовалось для запуска экземпляра служб Analysis Services, не было добавлено в учетные записи безопасности SQL Server.
в SQL Server 2012 SQL Server и Службы Analysis services по умолчанию настроены для работы от имени разных пользователей. Если вы выбрали значения по умолчанию, всегда убедитесь, что пользователь AS имеет доступ к вашему источнику данных!
проверьте, если у вас есть
User Instance=trueв строке подключения. Попробуйте удалить его, который решит вашу проблему.
У меня также была эта ошибка с аутентифицированным пользователем SQL Server
Я пробовал некоторые исправления, но они не работали.
решение в моем случае состояло в том, чтобы настроить свой "режим проверки подлинности сервера", чтобы разрешить проверку подлинности SQL Server в разделе среда Management Studio: свойства/безопасность.
единственный момент, который все, кажется, упустили из виду, что вы можете захотеть интегрированную безопасность = true. Возможно, сайт работает под учетной записью пула. Это все нормально, поэтому по-прежнему можно попасть на SQL server с исходными учетными данными пользователя, а не в пул. это называется ограниченным делегированием. Если вы включите его и настроите SPN, windows переведет учетные данные пула с запросами пользователя on, идущими в конечную службу (SQL-это только одна такая служба). У вас есть чтобы зарегистрировать один и только SQL server, который обслуживает запросы SQL на веб-сервере. Настройка всего этого слишком много для меня, чтобы попытаться точно описать здесь. Мне потребовалось довольно много времени, чтобы разобраться в этом самому.
Я потратил несколько часов, пытаясь исправить проблему, и я, наконец, получил его - браузер SQL Server был "остановлен". Исправление состоит в том, чтобы изменить его на "автоматический" режим:
если он отключен, перейдите в Панель управления - > Администрирование Сервис - >службы и найдите агент SQL Server. Щелкните правой кнопкой мыши, и выбрать Properties."Из выпадающего списка" Тип запуска " измените "Отключено"до " автоматически".
У меня была такая же проблема ранее, удаление
Persist Security Info=Trueот connectionstring работал для меня.
Я столкнулся с этой проблемой, когда клиент переименовал SQL Server. Служба отчетов SQL была настроена для подключения к старому имени сервера, для которого они также создали псевдоним, перенаправленный на IP-адрес нового имени сервера.
все их старые приложения IIS работали, перенаправляя на новое имя сервера через псевдоним. По какому-то наитию я проверил, работают ли они на SSRS. Попытка подключиться к сайту SSRS привела к ошибке:
"сервис не доступный.Обратитесь к системному администратору, чтобы решить эту проблему. Системные администраторы: серверу отчетов не удается подключиться к своей базе данных. Убедитесь, что база данных запущена и работает. Дополнительные сведения можно также проверить в журнале трассировки сервера отчетов. "
Он работал на сервере, но не смог подключиться, потому что он использовал псевдоним для старого имени сервера. Повторная настройка SSRS для использования нового имени сервера вместо старого / псевдонима исправлена.
