IIS Impersonation not working when app pool runs with domain account

Question

I have an ASP.net application running in an windows intranet environment. I have a requirement to perform certain database updates as the currently logged in user.

IIS/server info:

IIS version 10
Windows server 2019
ASP.net web forms application
.NET 4.7
Windows authentication enabled
Impersonation and anonymous authentication are disabled
The app pool uses integrated pipeline
The app pool runs with a domain service account for it's identity, which has rights to access other resources as needed.

Other details:

All of my database connection strings are set such that integrated security=true
in active directory, have configured constrained delegation between the web server and the SQL server, allowing MSSQLSvc : 1433 and MSSQLSvc (no port)
The domain service account is a member of the local administrators group on the web server (for testing purposes only)

When i perform the database updates that need to be done as the currently logged in user, i impersonate them in this way:

 var windowsIdentity = User.Identity as WindowsIdentity;
 WindowsIdentity.RunImpersonated(windowsIdentity.AccessToken, () =>
 {
     // perform database update
 });

This throws an exception - System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

If i change the app pool identity to use AppPoolIdentity (the default app pool identity) the impersonation works properly.

Why does this impersonation work with AppPoolIdentity, but not my domain service account?

cklimowski cklimowski · Accepted Answer · 2020-01-09T21:37:26

I've had similar issues before, I see your are using Kerberos, once you get it you'll be fine!

Something that worked for me in a similar scenario to yours is to open up IIS, go to your site, click Configuration Editor icon. In the top two headings, first click the "from" drop down and select "ApplicationHost.config and in the "section" heading to the left of "From", click the drop down, then expand the folders:

system.WebServer->security->authentication->windowsAuthentication,

From the options here, you can select "useAppPoolCredentials" and set it to TRUE, in your case.

When you have “useAppPoolCredentials” set to true you are telling IIS that it needs to use its application pool identity, which you are defining as the domain service account to decrypt the authorization ticket that is returned. The user profile typically doesn't have the provisions to do this.

Another thing to try if that doesn't work is to toggle the "Load User Profile" setting in the advanced settings of the app pool, I'm not sure if True or False will fix your issue, but it has seemed to help with similar issues before. I would try the above first and if that doesn't work then try this:

I didn't see anything mentioned about SPN's, are you using those? They can be required when running a domain account as the app pool ID. The below article documents that step as well as many others for getting this to work:

https://techcommunity.microsoft.com/t5/iis-support-blog/setting-up-kerberos-authentication-for-a-website-in-iis/ba-p/324644

Also, here are a few of many articles that greatly assisted me with getting this all to work at my job.

https://docs.microsoft.com/en-us/archive/blogs/chiranth/setting-up-kerberos-authentication-for-a-website-in-iis

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc961723(v=technet.10)?redirectedfrom=MSDN

Hope this helps.

UPDATE: For those still seeking help with this issue, we found a workaround for our system that did not require impersonation/delegation:

Instead we created another API endpoint, a "midpoint" that receives the request from the initial endpoint, without impersonation. In this scenario we were able to create an intermediate Sys Account to run as the app pool ID of the midpoint which is then the ID used to query the db, and this is the only access that sys account has, and this was enough for security team to be ok with it. We realized that logging the individual making the call would not be necessary when we use a special privileged system account, based on our protocols.

IIS Impersonation not working when app pool runs with domain account

1 Answers