Current windowsidentity same as currentrequest user identity with windows authentication

I have a weird issue with windows authentication. We have an asp.net webforms application in which we have a single folder that uses windows authentication. This folder is correctly configured for windows authentication in IIS. The application uses .net impersonation via the web.config. When we navigate to a page in this folder using windows authentication the:

• system.web.httpcontext.current.user.Identity.Name returns the name of the user that is doing the request (this is expected)
• System.security.principal.windowsIdentifier.getCurrent.Name returns the name of the user under which the application runs (this is also expected)

Now we have been working on a new version of our product for a long time. And we now find out that the behavior has changed. When we perform the same test again both the httpcontext user name and principal.windowsidentity.getcurrent return the name of the user that is performing the request.

We have checked all relevant code and we cannot seem to find any difference that has something to do with this behavior. We converted the application from .Net 4.0 to .Net 4.5.2 in the new version, however, when we convert the old version to .Net 4.5.2, the behavior stays correct (the 2 properties show a different identity) so that doesn't seem to be the difference.

Any thoughts on where to look for the cause of this behavior?

Edit: Debugging tells me the identity already has the wrong value when executing the global.asax prerequesthandler. In the beginrequest the impersonation of the web site has not been performed, and the current identity is the app pool identity

Edit2: It seems to be server specific. For some reason the old version works correctly on develop machines, but the new version doesn't. However, the new version DOES work correctly on deployment servers (our daily builds). Anyone has any pointers about a possible cause?

Right, I found the issue. The problem was that IIS added a web.config to the folder using windows authentication, in which it enabled impersonation on the folder. When both windows authentication and impersonation is enabled on the same folder, the behavior that both the windows identity and request identity are the same user is correct.

The situation we needed can be achieved by enabling windows authentication, but DISABLING impersonation on the folder. In this case the windows identity is the default web site's user, and the request identity is the windows identity of the user accessing the page