Fix for Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Are you getting this error? Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. 

Hopefully this will fix your problem, if it is similar to mine:

Today I was testing the implementation of a simple update command on a new Windows 2008 Web Server I had just setup:

Using con As New SqlConnection(bd.GetConnectionString)
Dim sql As String = _
" UPDATE blah set blah to blah"
Dim cmd As New SqlCommand(sql.ToString, con)
cmd.CommandType = CommandType.Text

The actual connection string was also very simple using Integrated Security:

add name="myConnectionString" connectionString="Data Source=xx.xx.xx.xx;Initial Catalog=MyDBA;Integrated Security=True"

But running this update generated the infamous:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

I had fixed this previously in 2008 when I had the same issue with my Membership Provider, so I suspected the same steps would resolve this problem.

In IIS7 on your Windows 2008 Web Server... 

Please go to Application Pools.

Select your web site.

Click "Advanced Settings" in the "Actions" panel.

Under "Process Model" select "Identity."

In the popup, select the "Custom account" radio button.

"Set" the account and password to your dbo account name and password that are used on your SQL Server 2008 database.

Save that.

Under sites, go to your website. In the Features View panel, select "Authentication" under IIS. Under ASP.Net Impersonation, make sure it's Disabled.



  • This issue can also be resolved by setting the <identity impersonate="true" /> value in the web.config file as well. Granted this will have the application connect to the database as the user logged into the website, but this can come in handy in Intranet scenarios.
    I'm curious as to the preference on setting the credentials in IIS as opposed to keeping the credentials in the web.config file and encrypting them. What advantages do you see to this route over the other?

  • Yes, in a typical environment you would not want your identity impersonate to be "true" with this setting; it should be "false."

    I prefer keeping all of my credentials out of my web.config file. I haven't researched why people do one over the other, I just feel it is more secure and I've always used windows autentication ever since the old asp classic days when people found out they could view the contents of your global.asa file.

  • "... your dbo account name and password ..."


    Unless you're writing an installer or a SQL Management Studio replacement, your application should *never* connect to SQL as any member of the dbo or sysadmin roles. Members of dbo have permission to do absolutely anything to your database; members of sysadmin have permission to do absolutely anything to the server.

  • RichardD,

    What is your solution then?

  • Use a specific user account which has only the permissions required by your application.

    If you can switch to SQL authentication, you won't need to change the identity of your AppPool; otherwise, you should create a low-privilege domain user and set your AppPool identity to that user. If SQL is on the web-server, you can use a local user instead.

  • @Richard: I think Nannett wanted to save a simple user account with sufficient permissions and not any dbo account with owner permissions.Wrong choice of word I guess!!!

    Nannett :Nice article!

  • When I received this error twice, I went to Designer, Selected my External Content Type, Selected Edit Connection Properties from the Ribbon, changed Authentication Mode from 'User's Identity' to Impersonate Custom Identity' and included my Secure Store Application ID. Then this error went away. I didn't have to touch any code and I'd rather not touch it if I don't need to.

  • this solution solved my problem. My ASP applcation was trying to impersonate the user but failed for login for user 'NT AUTHORITY\ANONYMOUS LOGON'. Thanks alot :)

  • I just enabled the ASP.NET Impersoantion 'Disabled' for WebSite under IIS Console, then the same exception had been removed.

  • same thing i had done but it did not fixed the issue

    my case same as yours except my app and db on different servers.

  • By default Entity Framework connection string has:

    Integrated Security=True;

    This should be removed from both the membership provider connectionstring as well as from the entity framework's generated connectionstring.
    At least This worked for my Entity framwork connection :)

Comments have been disabled for this content.