Impersonate Domain User with Integrated Pipeline

Question

In an local Intranet environment, are we doomed to use "Classic" pipeline mode in our App Pool if we want to use Impersonate our Windows domain users, or is there a new way to declaratively "run as" them (so-to-speak)?

My goal is to use Windows Authentication for local web applications on my Intranet so users can authenticate and run apps under their active directory account (principle). Every time I try this (Using the NetworkService identity of course), I get this error:

Answer 1

I wrote a small app to display the current user's network username grabbed from several different places such as Page.User.Identity.Name. I also grabbed information about the domain user using a couple different methods for querying Active Directory. All this to validate the following.

I have found two primary modes for running your application using Windows Authentication, which is primarily used in an Intranet environment according to my research. Here are the minimum essential elements of the configurations:

Classic Mode

• AppPool - Managed Pipeline set to Classic mode.
• AppPool - Identity set to Network Service.
• Authentication - Disabled: Anonymous Authentication
• Authentication - Enabled: ASP.NET Impersonation
• Authentication - Enabled: Windows Authentication
• Providers - Disabled: Kerberos
• Advanced Settings - Kernel Mode: Either

Integrated Mode

• AppPool - Managed Pipeline set to Integrated mode.
• AppPool - Identity set to Network Service.
• Authentication - Disabled: Anonymous Authentication
• Authentication - Disabled: ASP.NET Impersonation
• Authentication - Enabled: Windows Authentication
• Providers - Enabled: Kerberos
• Advanced Settings - Kernel Mode: Disabled

Now here's the kicker!!

If you want to use Integrated mode (which is ideal as it yields much more functionality, and well, integration) you will need to have enabled Delegation. Here are a couple must-read articles to understand the basics of Delegation, and by extension Dynamic SPN Registration. Since this gets into more Kerberos and security considerations that you probably care to delve into, it might be easier to just stick with Classic mode where all you have to do is enable Impersonation and call it a day; or else cheat and disable validateIntegratedModeConfiguration.

Answer 2

No, but "Integrated" pipeline requires you manually impersonate the Windows Authenticated user. At least in IIS8.5, that is.

Why? Classic impersonation break .NET's async features. Specifically, it is hard to manage the WindowsIdentity of a thread when it is being used by multiple users at the same time.

How? Use a WindowsImpersonationContext e.g.

// Start with identity assigned by IIS Application Pool var current = System.Security.Principal.WindowsIdentity.GetCurrent();  // Enable Windows Authentication in ASP.NET *and* IIS, which ensures  // User.Identity is a WindowsIdentity WindowsIdentity clientId = (WindowsIdentity)User.Identity;  // When 'using' block ends, the thread reverts back to previous Windows identity, // because under the hood WindowsImpersonationContext.Undo() is called by Dispose() using (WindowsImpersonationContext wic = clientId.Impersonate()) {     // WindowsIdentity will have changed to match clientId     current = System.Security.Principal.WindowsIdentity.GetCurrent(); } // Back to the original identity current = System.Security.Principal.WindowsIdentity.GetCurrent(); 

Problems? Sometimes you need to use delegation instead of impersonation.