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:
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
Integrated Mode
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
.