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.

Comments (7)

  1. Kris says:

    I ran into this problem (also referred to as the double hop issue with NTLM) a long time ago. Kerberos is the non trivial solution to this. I have a web app calling webservices hosted on another machine and I needed the identity of the user accessing the web app in the web services layer. It took me quite a while to get the Kerberos working. But I am glad to see someone from MS blogging about it.

  2. Alik Levin says:

    Kris, I am happy you got your app running. There is no issues with double hop with NTLM – it just does not work 🙂

    Notice "Authentication type" is "Negotiate" in the picture – that is kerb, otherwise it’d be NTLM.

    To pass identity over more than one hop one needs  Delegation which supported only by kerb – and that is what my next post is just about, that would be followed by Protocol Transition.

    Stay tuned and happy coding :)!

  3. alik levin's says:

    If these articles: How To: Implement Kerberos Delegation for Windows 2000 How To: Use Impersonation and

  4. alik levin's says:

    If these articles: How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0 Using Protocol

  5. alik levin's says:

    Windows Authentication Identity Flow Through Physical Tiers Identity Flow Through Physical Tiers – Impersonation

  6. alik levin's says:

    I was delivering "Authentication Explained" session for Security User Group. First of – thanks for attending

  7. I was delivering "Authentication Explained" session for Security User Group. First of – thanks