The error “Login failed for user 'NT AUTHORITY\\IUSR'” in ASP.NET and SQL Server 2008

天涯浪子 提交于 2019-11-28 00:43:43
Dave Markle

The trick here is that NT AUTHORITY\NETWORK SERVICE actually appears to the database as DOMAINNAME\MACHINENAME$ (note the $ sign!). That is, when you cross the machine boundary from your web server to the SQL Server, SQL Server sees the machine account if you use the NETWORK SERVICE or LOCAL SYSTEM accounts. If you use any other non-domain account, SQL Server will not receive your credentials.

I'm a bit puzzled by your error message. Truth be told, I don't think that when the DB is on another box, you'll see anything other than Login Failed for NT AUTHORITY\ANONYMOUS LOGON.

IUSR is used for anonymous websites, and can't pass over the wire to SQL Server. You may find a way for it to work if you're doing everything on the same machine, but I'd never know because I'd never do it that way... ;-)

I would suggest to create a separate (preferably domain) account and specify it in the connection string (usually in web.config) Then you can limit permissions on the web server what this account can and cannot do. Then you can grant this account required permissions in SQL server.

In case it helps someone, in web.config I added <identity impersonate="false" /> for this error to go away (under <system. web>)

I had had the same problem and solved this by changing application pool.

Instead of using Integrated Security=True; in connection string, just use username and password authentication user=sa; pwd=mypassword;

It's important to note that you'll get this error, as I just did, if you don't have IIS configured to allow impersonation, but, you have your web.config attempting to do impersonation.

I just came across this exact error, and all of the following steps are required (but I was missing the first step:

1.) Ensure ASP.NET impersonation is enabled on your IIS web server:

2.) Combine that with configuring your site to use impersonation (web.config):

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

3.) The above steps presume that you have a SQL Login setup on your MSSQL for 'your_service_acct' with permissions

When running on localhost, against a localdb, or even a remote db that you personally have permissions on, the development IIS runs as if it were YOU - and everything just magically works. So, in debug mode, you don't need to create a special web.config..

As soon as you deploy your site onto some kind of server (in my case, our TEST environment) you'll likely need to have done the above steps I just detailed, because IIS will try to connect as the application pool user, which is not usually what you want administratively speaking. So, that's when you want to start using web.config transformations, so Visual Studio will insert the appropriate identity impersonate="true" during your 'Publish...' deployment step.

mahmoud

This problem is shown when you restore a new database on your last database.

To resolve this you must go to sqlserver, then security and then set your apppool again.

The simple solution is to check your web.config file and make sure one of these is part of the db connection string:

Trusted Connection=false

OR

Integrated Security=True

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!