In the Basic Settings section of a website in IIS 7.5, there is an option to specify a user account via Connect As.... If this is kept off, pass through authentication is used.

I assumed that would use the identity of the Application Pool however this was not the case. In order to get my website to connect to MSSQL under the correct user account, I had to specify the user under the Connect As... screen.

So what is the difference between Connect As... and the Application Pool Identity?


I would speculate this may be related to the ability of the computer to impersonate the application pool identity over the network. The "Connect As" has the credentials saved (and encrypted), so it can create a full primary token and access resources as that user identity. With "Application User (pass through authentication)", that would be an existing token and attempting to use that token for impersonation. In that scenario, if the computer that is performing the impersonation is not trusted for delegation, it would not succeed.

This should be easy enough to test and validate.

Is the computer trusted for delegation? In Active Directory Users and Computers > Computer > Properties > Delegation tab. Select "Trust this computer for delegation to any service (Kerberos only)".

You may also need to set the IIS7 configuration setting "useAppPoolCredentials". This can be set with the following command:

appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true  

useAppPoolCredentials = True with Kerberos Delegation on 2008

Possibly related:


  • Seems like this is related too: blogs.technet.com/b/askds/archive/2008/11/25/… – Marcus Mar 4 '12 at 18:56
  • I'm pretty sure it will be the delegation issue, thanks. For simplicity I'll just leave the credentials under the Connect As dialogue box, unless there's any downsides? – Marcus Mar 4 '12 at 18:57
  • 1
    I reckon that one downside is it is another location that needs to be updated when the credentials change. – Greg Askew Mar 4 '12 at 20:12
  • I guess but for us the password won't be being changed. Now that it's entered into IIS, we won't be needing it in the future. If we create a new web site, we'll use a new user account to lock down access to the database. Thanks! – Marcus Mar 4 '12 at 21:34
  • As a note, Delegation is very powerful and can be exploited. I avoid it. docs.microsoft.com/en-us/windows/security/threat-protection/… – TheXenocide Feb 19 '20 at 17:18

I have found the reason why you might experience the following error when using Integrated Security for an MSSSQL Server connection string, despite the setting the application pool identity to be a user account that is able to login and have Pass Through authentication enabled in the Basic Settings of the web site:

Microsoft SQL Server Native Client 10.0 error '80040e4d'

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

Go to Authentication and then edit the Anonymous User - change from using the IUSR account by default to using the Application Pool Identity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.