I am currently working on an ASP .NET application which involves the user logging in using Windows Authentication. This causes both the HTTPContext.User and Thread.Principal to be set with the same credentials as the user logging in which is expected behaviour, while the WindowsIdentity stays as the IIS .NET AppPool user.
I have recently noticed in the application logs that there appears to be one request (normally the 5th-ish request on loading the page) where the WindowsIdentity starts off as the IIS user but ends up being elevated to the user who is logging in.
This only appears to be happening when the user is accessing the root path (for instance http://localhost/). If I specify any other exact path such as http://localhost/index.aspx this request does not appear to occur and the WindowsIdentity never changes.
Looking through the (rather large) codebase I can only find one method that impersonates a WindowsIdentity, but that method is not called apart from in specific circumstances on a specific page.
I was wondering why this might be happening and if there was any reason that IIS might be doing it by itself.
As per me i think the root(http://localhost) access is only for the administrator user , so it is checking where it is administrator user or not .. ,is the http://loclahost accessible if the user in not the administrator user ?
Related
We have an ASP.net app running on a pair of hosted servers. Access to the app is controlled by IIS using integrated Windows security. ASP code files are in one iis site while static content is served from another. The files sit on a UNC share \\10.x.x.1\mySites and are accessed by users running IE8 and 9.
In the last fortnight or so, the application users are finding it difficult to access the site. Now, when they request the URI they get presented with the standard login box which reappears after every single attempt at gaining access. After a half a dozen attempts the process ends with a '401 Not Authorized' error.
This is odd enough, but after getting one of our network guys to take a look at it, it turns out that the credentials the user typed into the IIS password prompt are not being transmitted to IIS - rather its the credentials (Windows login Id & password) of the current user that are.
Can anyone shed any light on what is happening?
I think IIS holds user account credentials separately in order that it can proces anon access. If this gets out of sync with the corresponding system credentials for the anonymous account, this sort of thing can happen. Have a poke around, I think there is a way to reset IIS.
How to get windows authenticated user name in .net application? My app is hosted on IIS. There is no Login form. But, I want to get the windows user name of the persons browsing it. I tried all the request objects. principal object getcurrent().name returns IIS app pool user name. But not the actual user. Please help. Thanks.
You cannot. Unless your application is using windows auth (and they could be prompted at some point like in firefox) you cannot get this information. If you do allow it, then access it via http://msdn.microsoft.com/en-us/library/system.web.httpcontext.user.aspx
HttpContext.User.Identity.Name
again though - they could be prompted for a login at some point.
You can't unless you enable windows authenication.
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 have a website in IIS 6.0 using an application pool with a custom service account. When I browse the website, I get an error "service unavailable" and the error in event log says
The identity of application pool 'SampleAppPool' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool. Therefore, the application pool has been disabled.
I think the utility "Aspnet_regiis" can be used to grant access to an account to IIS metabase according to this article, but is that the right way to fix this issue? Because this utility is used for multiple things and may do more than just granting the permissions to the account, or should I just add the account manually to IIS_WPG group?
When I see this in IIS 6 and the user has a custom app pool identity, the problem typically originates in the entry of credentials in the app pool properties. So there are generally two origins for the issue.
One is a simple typo in the credentials, unfortunately the form validation is not very good in IIS 6, so I often will have users change the identity of the app pool, then immediately check that the credentials "took" and/or check the System event log for W3SVC and related errors.
The second specific cause I see in this scenario is when people enter an Active Directory user, they sometimes forget to add the domain name. (e.g. DOMAIN\Username). Which leads me to the next point, the IIS_WPG is the builtin local group which grants members the required ACLs to run as an app pool identity. The aspnet_regiis.exe -ga grants the same thing to users, but IMO it is best suited for use when the IIS_WPG group is not an option. Also a dedicated app pool user account is generally a good idea. If the AD user password is changed, you'll bring your app to its knees until you again re-enter the credentials in the IIS Manager.
Edit: I added some para breaks to make this chunk more readable.
I had this same problem and I resolved it by starting the application pool. Ours was stopped even though IIS was running.
"The identity of application pool 'SampleAppPool' is invalid..."
Every time I have had that error, it was because the user name and password where not correctly entered in the application pool. This happens also when you import the pool settings from another server. Reentering the password in the application pool identity configuration has always solved the problem.
Once you get that right, you will probably meet the second problem you are describing, but that's an unrelated issue. It can be fixed as you describe, or even manually granting the required access permissions to the application pool identity.
If you are connecting to a remote machine using one or more remote access tools, take note: your keyboard mappings may be getting screwed up somewhere along the way!
In my case, I tried typing out certain letters of the password in a plain text editor on the remote machine (not necessarily in the same order, to retain security). When attempting to type the dollar character, I found that if I used the left shift key I got a "$" but if I used the right shift key I got a "4".
Once I had that figured out, I could enter the correct password for the Application Pool Identity. (Note: when filling out the identity section, IIS does not validate the password you enter against the user identity, only that the two passwords you enter match each other).
I have an application we bought that I need to integrate, and it uses jakarta connection to get to the application from IIS.
So, the basic operation is:
user goes to the url
Gets redirected to the application
SSO is enabled, so redirected back
to IIS for fetching of domain
credentials
Back to application
If username is blank show login
page, else let user in.
This is a simplification of all the steps, but the basic idea is here.
My difficulty is that I need both Windows Integrated Auth and anonymous on, as some users won't have credentials, and need to be prompted for a username/password.
I have looked at: IIS Windows Authentication before Anonymous already, but the user doesn't get to click on a link to decide. The application goes back to IIS looking for login.aspx and from there I want to either get their domain credentials or pass back to the application empty strings to signify that there are no credentials.
It seems this isn't going to be possible though as if anonymous is on it doesn't make the 401 request so the credentials aren't passed.
If I can't get this to work with just using an ASP.NET page, could it be done using an ISAPI filter, or a module?
UPDATE:
I found a possible solution, but I need to figure out how to get it to work, as my login page is on the JBoss server.
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx
Keep the Authentication in the IIS as the Anonymous.
When loading the home page check the ACTIVE DIRECTORY for the current logged in USERNAME if exist
provide the extra functionality to current user or else with fewer options.
Refer --> Active Directory Cheking