Ошибка входа в систему для пользователя NT AUTHORITY \ IUSR в ASP.NET и SQL Server 2008.

Уловка здесь в том, что NT AUTHORITY\NETWORK SERVICE фактически отображается в базе данных как DOMAINNAME\MACHINENAME$ (обратите внимание на знак $!). То есть, когда вы пересекаете границу компьютера с веб-сервера на SQL Server, SQL Server видит учетную запись компьютера, если вы используете учетные записи NETWORK SERVICE или LOCAL SYSTEM. Если вы используете любую другую учетную запись, не относящуюся к домену, SQL Server не получит ваши учетные данные.

Я немного озадачен вашим сообщением об ошибке. По правде говоря, я не думаю, что когда БД находится в другом ящике, вы увидите что-то кроме Login Failed for NT AUTHORITY\ANONYMOUS LOGON.

IUSR используется для анонимных веб-сайтов и не может передаваться по сети на SQL Server. Вы можете найти способ, чтобы это работало, если вы делаете все на одной машине, но я никогда не узнаю, потому что я бы никогда не сделал это таким образом ... ;-)

Если это кому-то поможет, в web.config я добавил <identity impersonate="false" />, чтобы эта ошибка исчезла (под <system.web>)

Я бы предложил создать отдельную (желательно доменную) учетную запись и указать ее в строке подключения (обычно в web.config). Затем вы можете ограничить разрешения на веб-сервере, что эта учетная запись может и не может делать. Затем вы можете предоставить этой учетной записи необходимые разрешения на сервере SQL.

Важно отметить, что вы получите эту ошибку, как и я, если у вас нет IIS, настроенного для разрешения олицетворения, но у вас есть файл web.config, пытающийся выполнить олицетворение.

Я только что наткнулся на эту точную ошибку, и требуются все следующие шаги (но мне не хватало первого шага:

1.) Убедитесь, что на вашем веб-сервере IIS включено олицетворение ASP.NET:

2.) Совместите это с настройкой вашего сайта для использования олицетворения (web.config):

   <system.web>
     <identity impersonate="true" userName="your_service_acct" password="***" />

3.) Вышеупомянутые шаги предполагают, что у вас есть настройка входа в SQL на вашем MSSQL для 'your_service_acct' с разрешениями

При работе на localhost, против localdb или даже на удаленной базе данных, на которую у вас лично есть разрешения, разработка IIS выполняется так, как если бы это были ВЫ - и все просто волшебным образом работает. Таким образом, в режиме отладки вам не нужно создавать специальный файл web.config ..

Как только вы развернете свой сайт на каком-то сервере (в моем случае, в нашей тестовой среде), вам, вероятно, потребуется выполнить описанные выше шаги, которые я только что подробно описал, потому что IIS попытается подключиться как пользователь пула приложений, что является не обычно то, что вы хотите с административной точки зрения. Итак, вот когда вы хотите начать использовать web.config transformations, поэтому Visual Studio вставит соответствующий identity impersonate="true" на этапе развертывания" Опубликовать ... ".

У меня была такая же проблема, и я решил ее, изменив пул приложений.

Вместо использования Integrated Security=True; в строке подключения просто используйте аутентификацию по имени пользователя и паролю user=sa; pwd=mypassword;

Эта проблема проявляется при восстановлении новой базы данных в последней базе данных.

Чтобы решить эту проблему, вы должны перейти на sqlserver, затем на безопасность, а затем снова установить свой пул приложений.

Простое решение - проверить файл web.config и убедиться, что один из них является частью строки подключения к базе данных:

Надежное соединение = false

OR

Интегрированная безопасность = True