IIS Identities: Application Pool vs Connect As in Basic Settings

Solution 1:

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
https://blogs.technet.com/b/proclarity/archive/2011/03/08/useapppoolcredentials-true-with-kerberos-delegation-on-2008.aspx

Possibly related:

https://stackoverflow.com/questions/3775569/help-with-kerberos-authentication-in-iis-7

Solution 2:

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.