Identity Flow Through Physical Tiers - Impersonation

There are scenarios where actual windows identity  of end user needs to be flowed to the server so that server can perform action on end user's behalf - that is in nutshell Impersonation. In previous post Identity Flow Through Physical Tiers - one might think that the end user identity flowed but in fact it was not. Although HttpContext held end user's account - DEMO\Administrator - and even identity's type was WindowsIdentity, the actual windows thread was ran under Application Pool's account - DEMO\W3WRUNNER1. That means that the resources were accessed under App Pool account - DEMO\W3WRUNNER1 - just as depicted in the post.

While scenario is the same where user sits behind her machine A and access simple ASPX page on box B that access file on share on box C, like this:

lets do some small changes, and define impersonation in web.config file:

Now lets access the aspx page:

Seems like impersonation works - both HttpContext and windows thread has the same, end user's identity - cool, good job.

But when the code reaches the line where the file on share (Box C) is accessed, something goes wrong:

Why? It worked in previous post...

The reason for such behavior is that I got my architecture confused...

On one hand I asked app process, sorry, specific request's thread to run under end user's account - Impersonation - by setting impersonate="true" in web.config. On other hand I ask this thread to go out to network resource - my file on file share. That is another Impersonation... In scenario where the resource sits on the same box, Web Server B, impersonation would work, but in our case - the resource sits on other machine C.

In other words  I am trying to flow identity over two hops - from end user machine A to web server B and then to File share C - that is more than Impersonation, but Delegation which will be discussed in the next post.