ASP.Net exposes a handy Windows feature called Impersonation. This lets an application access local resources using the credentials of the current user. Local resources is important – if you want to access some files, then that’s fine, but if you want to access a remote database, you’re going to need Delegation as well.

It’s fairly simple to set this up once you know what needs doing. Getting to that stage wasn’t the most fun I’ve ever had – the MSDN articles on the subject are useful, but they seem to want to cover at least 3 topics at a time, which can be a little confusing.

The scenario was this: an intranet web application would authenticate users using Windows Authentication, granting access based on their Active Directory roles. The application would access the back-end SQL Server database using Integrated Security, with the credentials of the current user. This gives two main advantages – you don’t have to setup or administer a separate account or accounts for the database, and auditing via SQL triggers is easy. However, this approach is only really suited to an intranet scenario, as database connection pools are used on a per-user basis. Too many users and the database will not be happy.

The setup is in four parts.


Under the <system.web> section of your web.config, add the following:

<authentication mode="Windows"/>
<identity impersonate="true"/>

Also, make sure you’re using a connection string that uses Integrated Security.


I’m using IIS7, which has some more detailed settings than IIS6. In the website or virtual directory, ensure that Anonymous Authentication and Forms Authentication are disabled, and ASP.Net Impersonation and Windows Authentication are enabled. IIS should pick this up from web.config.

IIS Authentication section

IIS7 lets you specify “providers” for Windows Authentication. You must use the Negotiate:Kerberos provider. Choosing this provider will mean that “Kernel-mode authentication” cannot be used. This is disabled under the Advanced Settings within the Authentication section.

Active Directory

The web server’s Active Directory properties must be edited to enable Delegation of credentials onto the SQL server. There’s a great explanation with a screen grab of the Active Directory property page in a post from Ken Schaefer.

Windows Server 2003 domains and later support Constrained Delegation, which can constrain the delegation to a specific service on the target machine. This is obviously more secure. To delegate to SQL Server, MSSQLSvc is the service you need.

SQL Server

All you need to do at the database level is grant the relevant permissions for the users or roles you want accessing the database.

Now it should all magically work!

UPDATE: That might not be all! See Part 2.

4 comments so far

Add Your Comment
  1. In a previous post I explained how to configure Impersonation and Delegation in ASP.Net […]

  2. I just wanted to say thank you so much for this post. I’ve been pulling my hair out all week trying to get this working, it turns out that the Active Directory setting was all I was missing. This post solved my issues from start to finish. Thanks, Great Post!

  3. An EXCELLENT and very succinct step-by-step article on setting up Impersonation with your ASP.NET website within an intranet environment. If only I’d have known at the time that the answers were contained within before exploring elsewhere. Readers, be sure to read this article carefully before moving on. For me, the issue was that AD hadn’t allowed my server for Delegation which led to countless hours of struggle. Thank you Graham. :)

  4. I have read in other posts that you have to change the AppPool ‘Managed pipeline mode’ to Classic (from Integrated). I had to make this change in IIS7.5 to get things working but I was hoping to avoid this. I notice that there is no mention of it here. I was hoping someone could confirm whether the approach described above does indeed work with AppPool ‘Managed pipeline mode’ set to Integrated. Thank you