A couple of days ago a friend asked me a question about a problem he had with Windows Authentication and I thought I’d share some of the information about it.

They have an ASP.NET web application that have Windows authentication enabled. That application is accessing another server using an API. So far so good.

When they logged into the web application using Windows authentication, the credentials were automatically transfered and validated through IIS and the thread executing the current request was automatically impersonating using the credentials that were passed from the browser, but the call to the API within the application that accesses the other server failed.

This happens due to the fact that NTLM, the protocol that is used be default in Windows Authentication (and even used by default when installing a new domain server) does not support, due to various reasons, credentials delegation.

This means, that only the hop from the browser to the web server is supported and the credentials are not being transfered again from the web server to the other server through the API.

This will happen in every ASP.NET web application or web service that uses Windows authentication.

There is a nice post in this blog, that describes the problem as well as the possible solutions which includes (in a very short list):

  • Basic Authentication – An IIS feature that uses clear text over the wire to authenticate, which is not secure so consider using HTTPS to perform that.
  • Kerberos – a security protocol that is supported in Active Directory (Windows domains start are based on Windows 2000 and above). Kerberos is a bit annoying to configure, so it might not be the best possible solution (and sometimes your IT guys won’t even support it anyway).
  • Specify explicit credentials – This means that the second hop to the other server from the web server will always use the same predetermined fixed credentials. Sometimes you simply cannot do that, but that solely depends on your implementation.

The blog post also contains some links to knowledge base articles that can help you configure Kerberos as well as how to use explicit credentials.

  • dominick


    well – this will only happen when ASP.NET is impersonating the client.

    Either disable impersonation using the identity elelemt in web.config
    or undo impersonation manually in code using


  • Hello Dominick,

    Disabling the impersonation won’t help since eventually I DO want to delegate (in certain situations like the one I’ve described in the post) my credentials onwards.

    If I’ll undo the impersonation the security context of the current request will revert to the security context of the process running ASP.NET (either ASPNET_WP.exe or W3WP.exe) and usually, the credentials at this stage are very low and practically doesn’t allow me to do anything (and in most cases, it will not give me access to the network).

  • Kerberos is the “proper” way to do this and is not so difficult to set up. If your IT guys are worth their salt they’ll already have set up a secure network infrastructure, otherwise they should be willing to do so.

    As long as you ensure delegation is configured on the correct objects in AD, and you configure IIS to use Windows authentication and impersonation it’s relatively straightforward to configure. There is a bit of a learning curve on the first time but that’s why we like IT, right? 😉