I have a small ASP.NET test script that opens a connection to a SQL Server database on another machine in the domain. It isn't working in all cases.
Setup:
IIS 7.5 under W2K8R2 trying to connect to a remote SQL Server 2008 R2 instance. All machines are in the same domain.
Using the ApplicationPoolIdentity for the web site it fails to connect to the SQL Server with the following:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
However if I switch the Process Model Identity to NETWORK SERVICE or my domain account the database connection is successful.
I've granted the \$ access in SQL Server.
I am not doing any sort of authentication on the web site, it is just a simple script to open a connection to a database to make sure it works.
I have Anonymous Authentication enabled and set to use the Application pool identity.
How do I make this work? Why is the ApplicationPoolIdentity trying to use ANONYMOUS LOGON? Better yet, how do I make it stop using the Anonymous logon?
I had the same issue as well. As per this page, the ApplicationPoolIdentity is supposed to access network resources as the machine account (DOMAIN\COMPUTERNAME$), but it was using NT AUTHORITY\ANONYMOUS LOGON to access SQL server instead.
I was able to use this hotfix to get ApplicationPoolIdentity working as the doc says it should. This hotfix doesn't specifically describe a solution for accessing network resources as NT AUTHORITY\ANONYMOUS LOGON, but it's related to the computer password changing.
This stackoverflow thread helped me find this solution:
Other useful tips for debugging ASP.NET identity and SQL identity
Since SQL integrated auth is related to the thread identity, it's useful to be able to view your user identity, thread identity (which changes depending on impersonation), and the SQL server login. This ASPX snippet displays all three:
I had the exact same issue. I pulled my hair out for several hours and finally rebooted the machine. The issue went away! Note that restarting IIS via iisreset DID NOT solve the issue. It only went away when i restarted the server.