ASP.NET Impersonation
I have a site hosted on IIS that has anonymous authentication and forms authentication both enabled.
Initially I have impersonation Turned Off. So before logging in using forms authentication for,
System.Security.Principal.WindowsIdentity.GetCurrent().Name
I get a value of IIS APPPOOL\DefaultAppPool
when i enable impersonation I get a value NT AUTHORITY\IUSR
After logging in with forms authentication regardless of whether I have impersonation turned or or off.. I am always getting a value of IIS APPPOOL\DefaultAppPool
My question is.... if I have impersonation turned on and I log in using JSMITH's account, shouldn't I be getting a value of JSMITH
Impersonation doesn't run as the user you've logged in as, it just allows you to run your application under a specified user account.
<identity impersonate="true" userName="domain\username" password="P#$$word"/>
This will run as domain\username.
If you want to use the user account that's logged in you will want to look at something like Forms Authentication or Windows Authentication.
Related
I've an ASPNET MVC3 application running fine on Forms authentication on IIS10. When I've tried to change to Windows authentication, I want to use LogonUserIdentity.Name to check the username on my own users table but on the first request it's working fine and returning the name of the Logged user on the system but on all other (ajax) requests is returning the IIS User.
What could be wrong? I've searched a lot and verified the following article (https://richhewlett.com/2011/02/15/getting-a-users-username-in-asp-net/) and I've Windows authentication enabled and impersonation disabled (not defined really).
I have a web app, in the web.config, I have following settings:
<authentication mode="Windows"/>
<identity impersonate="true" userName="domain01\user01" password="***"/>
I deployed the app to Windows 2008 (IIS 7), the Identity of the application pool is domain01\user01, and in the Authentication of the app, I have following set:
Anonymous Authentication Disabled
ASP.NET Impersonation Enabled
Basic Authentication Disabled
Digest Authentication Disabled
Forms Authentication Disabled
Windows Authentication Enabled
Now I need to get the user name who is currently logged on the machine, could be any authorized user with different domain. But no matter what I tired, I always got the impersonated user domain01\user01. I tried, HttpContext, WindowsIdentity, etc. Does anybody know how do I get the correct user name without changing my settings?
You are specifying domain01\username as the identity that you want to impersonate. That is why the current user is always that. If you remove the configured identity you will get the actual logged in user.
<identity impersonate="true" />
This is documented here:
http://msdn.microsoft.com/en-us/library/xh507fc5(v=vs.85).aspx
If I impersonate a user in the web.config but the application runs under an application pool which uses another identity, which identity would be used when you access resources (say files) on the server?
Another question, can you run a page under a separate identity from rest of the application?
When you access resources on the server the user will be the one specified on the impersonation configuration NOT the one on the application pool
Impersonation enabled for a specific identity. In this instance, ASP.NET impersonates the token generated using an identity specified in the Web.config file.
<identity impersonate="true"
userName="domain\user"
password="password" />
Impersonation enabled. In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous Internet user account.
<identity impersonate="true" />
Source: MSDN
In case you're interested, here you have an article with a Identity matrix for different impersonate scenarios.
And yes, you can impersonate programatically as Alex Dn said
1) In web.config.
2) You can do impersonation in code behind:
http://support.microsoft.com/kb/306158
or Another article
Could somebody please help me understand the concept of 'impersonation'?
The way I understand it is that when impersonation occurs, code executes on behalf of some identity.
So, for a web page, as long as impersonation is disabled, the web page will always run under its configured account.
If it’s enabled, I can ‘override’ its default account and set the account under which I want the web application to run.
So if I'm using IIS7 and I have the following:
- An application pool with identity set to a Custom account ‘user1’.
- An asp.net web site, with its application pool set to the one above, and with impersonation disabled.
- Windows authentication enabled.
I also have the following code:
IIdentity ii= Thread.CurrentPrincipal.Identity;
IIdentity iii = Page.User.Identity;
If I access the page, I’m asked for windows credentials, I introduce ‘user2’ credentials.
As impersonation is disabled, I’d expect the IIdentity name to be ‘user1’, which it isn’t its ‘user2’.
Can somebody help me understand what’s going on? I guess I completely misunderstand the concept of ‘impersonation’.
Thanks
UPDATE 1
I came across this link after searching for a while:
http://msdn.microsoft.com/en-us/library/aa302377.aspx
It seems like there are three IIdentity objects.
HttpContext.Current.User.Identity
Thread.CurrentPrincipal.Identity
WindowsIdentity i2 = WindowsIdentity.GetCurrent();
From the link I understand that:
HttpContext.Current.User.Identity: Represents the current user requesting the page.
Thread.CurrentPrincipal.Identity: Identity currently executing the thread. I guess that this identity will be the one under which the current web request runs and its asp.net roles will define what the user can and can’t do in the application.
I suppose most of the times both HttpContext.Current.User.Identity and Thread.CurrentPrincipal.Identity would be the same user, but for some scenarios I guess the user requesting the page and the Thread.CurrentPrincipal.Identity could be different.
Then there’s:
WindowsIdentity i2 = WindowsIdentity.GetCurrent();
The link says: “WindowsIdentity = WindowsIdentity.GetCurrent(), which returns the identity of the security context of the currently executing Win32 thread.”
After doing a few tests enabling a disabling ‘impersonation’ and for my current scenario, I find that this is the Identity that gets impersonated.
If I don’t impersonate, ‘WindowsIdentity.GetCurrent();’ would reflect the configured user in the application pool and if I do impersonate, the identity changes to the one I’ve set in web.config:
<identity impersonate="true" password="**" userName="****" />
UPDATE 2
And if I set the web.config as:
<identity impersonate="true" />
WindowsIdentity.GetCurrent() gets impersonated as the user making the request so:
HttpContext.Current.User.Identity
Thread.CurrentPrincipal.Identity
WindowsIdentity.GetCurrent()
Are the same user, the user requesting the page.
When using impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they are operating. The usual reason for doing this is to avoid dealing with authentication and authorization issues in the ASP.NET application code. Instead, you rely on IIS to authenticate the user and either pass an authenticated token to the ASP.NET application or, if unable to authenticate the user, pass an unauthenticated token.
From Very good Article ASP.NET Impersonation
I've seen other answers saying how to secure virtual folders for Windows Authentication only. I would like to allow both anonymous AND Windows Authentication in IIS, but prioritise Windows Authentication over Anonymous Authentication. The reason for this is that the web app I am building needs to support anonymous access as well as privileged.
Is this possible? I.e. if Windows Authentication cannot authenticate against the domain, it will fall back to a generic identity, as opposed to the way it works out of the box by favouring anonymous access.
Developing on W7 with IIS.
You could do the steps in this article: http://msdn.microsoft.com/en-us/library/ms972958.aspx
And then just don't redirect to a login page. Basically you trap the authentication error and keep going.