I just migrated a development workstation

  • FROM: Windows XP Pro SP3 with IIS 6
  • TO: Vista Enterprise 64bit with IIS 7

Since the move, one of my pages that accesses an SQL Server 2000 database is receiving the following error from my ASP.NET 2.0 web page: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'."

I have:

  • enabled Windows Authentication in IIS and web.config
  • disabled Anonymous Authentication in IIS
  • set up Impersonation to run as the authenticated user
  • verified that the logged in user (in this case, me) has access to the appropriate database on the SQL Server
  • verified that my login and impersonation information is correct in the ASP.NET page by checking User.Identity.Name and System.Security.Principal.WindowsIdentity.GetCurrent().Name (both display my username)

My connection string using SqlConnection is "Server={SERVER_NAME};Database={DB_NAME};Integrated Security=SSPI;Trusted_Connection=True;"

Why is it trying to login with NT AUTHORITY\ANONYMOUS LOGIN? I have to assume it's some setting or web.config entry specific to IIS7 since it worked fine before the migration.

NOTE: The SQL Server is Windows authentication only - no mixed mode or SQL only.

  • 1
    Is the web application running on a different system then the desktop? So are you doing the following: Vista -> web server -> SQL Server? Jul 15, 2009 at 20:06
  • As Brian asked, I wonder if it's the double hop issue.
    – Bratch
    Jul 16, 2009 at 0:25
  • The web application is running on the workstation. It is Vista+webserver -> SQL Server
    – Rick
    Jul 16, 2009 at 12:45

5 Answers 5


Looks to me like constrained delegation is not enabled: Configuring Servers for Delegation.

  • Is delegation how you fix the double hop issue?
    – Bratch
    Jul 30, 2009 at 3:03
  • Yes. Delegation enables establishment of trust between the last node and the middle node that impersonates the starting node, thus resolving the impersonation in double hop issue. Jul 31, 2009 at 0:06
  • I have spent SOOOO long cheking though kerberos related configuration. Browser -> Sharepoint -> Performancepoint -> Analysis Services. Never helped by a total lack of documentation about how each stage builds the SPN for the next hop! Has anyone made constrained delegation using NTLM work?
    – pipTheGeek
    Aug 20, 2009 at 18:36
  • @pip: Constrained delegation through NTLM? I don't think that will ever work, delegation is supported only with Kerberos. Aug 22, 2009 at 20:31

I know its a litlle late reply, but I also stumbled into the same problem and resolved this. Thought to share with you all.

I can understand why you may not want to introduce SQL authentication as client may not be in favour of that.

To make Windows Authentication to work, you may folow following steps:

1) In web.config specify authentication to windows

2) In web.config Impersonate identity to true

3) Create a new domain virtual user for the application, say [email protected], with some password

4) In the impersonation section, specify this userid and password

5) In IIS, remove anonymous access and check integrated windows authentication

6) Provide access to this new user access to IIS metabase using aspnet_regiis -ga "mydomain\username"

7) Provide access to this user access to physical directory of your virtual directory. You will need to add this user there.

8) Note that if your application is writing to some log file, you will also need to provide 'write' rights as well

9) Note that if your application is accessing some database with execution of some stored procs, you will need to add this user to sql server logins with dbowner right to the application database.

Also, you may not want to fall into the security trap by providing access to NT Authority/Anonymous Logon, so in this case creating your own application user will help.

I hope it helps and if it does request you to make this as 'Answer'


I was suffering from the same problem, with a SQL Server 2008 DB. While there are probably different ways to solve this, thanks to Adam's link, I was able to find this section, which solved my situation:

5) Windows Authentication is performed in the kernel by default. This may cause HTTP clients that send credentials on the initial request to fail.

IIS 7.0 Kernel-mode authentication is enabled by default in IIS 7.0. This improves the performance of Windows Authentication, and simplifies the deployment of Kerberos authentication protocol. However, it may cause some clients that send the windows credentials on the initial request to fail due to a design limitation in kernel-mode authentication. Normal browser clients are not affected because they always send the initial request anonymously.

NOTE: This breaking change applies to both Classic and Integrated modes.

Disabling 'Kernel Mode' in IIS Manager solved the problem, sending the credentials correctly.


Did you try editing the application pool and changing the Managed Pipeline Mode to Classic instead of Integrated?

It might be related to breaking changes in IIS7 for ASP.Net 2.0 applications.

  • That does not seem to be the problem. Classic mode did not fix it.
    – Rick
    Jul 15, 2009 at 20:21

Maybe add local network service account to the database on SQL.

Hope it helps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .