Windows Authentication And Impersonation

Very often we are confused by the authentication and impersonation settings in asp.net web config, coupling that with the settings of IIS and NTFS file system, to have a clear idea of who has access of what of your resources just seems an insurmountable chain of hurdles.

On the other hand, security is a serious issue for any web application, a good understanding of every point of this chain is necessary for a secure and reliable system.

As usual this article is a document that records all the struggles I have had with these concepts for the most complicated and most likely scenario: windows authentication – integrated.

The mission here is just to work out who the identity of the thread owner is at the end of this impersonation or delegation chain.

The best way to explain this is a table from this MSDN article:

First we have 3 different identities in our asp.net application :

 //Authenticated user
 string _user = this.User.Identity.Name;  // get the windows user

 //the identity of the security context of the Win32 thread
 WindowsIdentity winId = WindowsIdentity.GetCurrent();
 WindowsPrincipal winPrincipal = new WindowsPrincipal(winId);
 _user = winPrincipal.Identity.Name;

 //Original principle in thread
 _user = Thread.CurrentPrincipal.Identity.Name;

as a result of different combination of configuration, they yield different output accordingly

Web.config settings Variable location Resultant identity
<identity impersonate="true"/>
<authentication mode="Windows" />
HttpContext
WindowsIdentity
Thread
Domain\UserName
Domain\UserName
Domain\UserName
<identity impersonate="false"/>
<authentication mode="Windows" />
HttpContext
WindowsIdentity
Thread
Domain\UserName
NT AUTHORITY\NETWORK SERVICE
Domain\UserName
<identity impersonate="true"/>
<authentication mode="Forms" />
HttpContext
WindowsIdentity
Thread
Name provided by user
Domain\UserName
Name provided by user
<identity impersonate="false"/>
<authentication mode="Forms" />
HttpContext
WindowsIdentity
Thread
Name provided by user
NT AUTHORITY\NETWORK SERVICE
Name provided by user

Points that will help us to understand:

1.Authentication and impersonation are two different concepts. Your request will first reach IIS, authentication involves how IIS check identity of the request and decides if request is eligible, if yes, IIS will delegate the request on to your application, here impersonation is responsible for which role the application is run under. I do not think there is any problem about the authentication process, the complexity comes from impersonation.

2. Default impersonation is turned off, so there is no impersonation, all applications are running using the IIS worker thread. For xp and earlier windows versions, the default user is ASPNET, newer versions the user is Network Service, these are default values, they also can be changed.

3. When impersonation is on, the worker thread will be run under authenticated users or a particular user “TestUser” in the following case:

<identity impersonate="true" username="TestUser" password="P@ssw0rd" />

4. Another important concept is : among 3 type of identities as above, the second one
WindowsIdentity.GetCurrent() is the one who actually is trying to access the resources, even when impersonation is turned off,you still can get identity of logged in user through two other ways.

5. Under IIS, windows authentication mode, you still can enable anonymous, I found it very confusing how you can stay anonymous in a controlled windows environment, when it is enabled, IIS will not even authenticate the user in the first place, so everyone is given access and if impersonated, then anonymous account is the runner.

6. Well my above theory is 99% right, I am not sure it is a bug or not, if your application spawns another process, like what I did in my html to pdf blog, impersonation will not apply at all no matter you turned it on or off. The spawned process is always using the IIS worker principle Network service.

7. You can debug your application from IIS rather than the development server to see the delegation by IIS

8. There is a trick on NTFS security settings, that is ‘deny’ will take precedence of ‘allow’, so be aware of deny access defined in special permission, if the access is inherited from parent, you can just uncheck : Inherit from parent permission, and remove the allow entry, rather add a deny entry.

9. Windows Authentication provider is disabled as default for Windows Server and Vista
Here are instructions to enable it on vista

10. When using windows authentication with anonymous disabled, exceptional location anonymous grant like this:

<location path="foldername">
      <system.web>
         <authorization>
            <allow users="?"/>
         </authorization>
      </system.web>
 </location>

is not working, it is only relevant for forms authentication.

Tags:

This entry was posted on Thursday, September 30th, 2010 at 2:11 am and is filed under ASP.NET. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

*