We have a website displaying some strange behaviour. It was just updated from ASP.NET v2 running on IIS6 to .Net v4 running on IIS7.5.
It is only used within the intranet and uses Windows Authentication, but the user sessions do not appear to be maintained as I would expect.
The situation is this:
Person A logs in - all good.
Person B logs in - all good.
Person A refreshes their page, and they are now logged in as Person B.
Person C logs in, and now Person A & B are both logged in as Person C.
We are getting the current logged in user by way of
System.Security.Principal.IIdentity winId = HttpContext.Current.User.Identity;
I'm kind of baffled as to what's going wrong here. Does anyone have any ideas?
Related
So I have set up a IIS 7 server with windows authentication, and all works well. I have an aspx (test page) returning the users name and groups.
Code:
IIdentity WinId = HttpContext.Current.User.Identity;
WindowsIdentity wi = (WindowsIdentity)WinId;
string userDomain = wi.Name.ToString();
the userdomain string returns (example) "DOMAIN/username"
however, I have only one user on my domain (same active directory groups as similar users) but he returns "Server/administrator". I checked all the groups in security and he doesn't belong to them. So im out of ideas.
EDIT: See my answer below (figured it out)
There are two places storing user accounts, local SAM store and Active Directory.
If you see "Server\username", it means you have logon to the machine using an account from local SAM store.
If you see "Domain\username", it means you have logon to the machine using an account from Active Directory
The confusion usually comes up when you have a local user account with the same user name as a domain user account. The built-in account "administrator" is usually one of the most common accounts causing this confusion.
In order to make sure you logon using a domain account but not a local user account, you can specify fully qualified name at the logon time. e.g. Domain\Administrator or Server\Administartor
Figured it out. He had a certificate attached to his user account that didn't get destroyed when using remote desktop connection. Thanks anyway.
I have a user who got married and changed id from MJones to MSmith however MJones still displays on welcome page of my app. I use Context.User.Identity.Name to get the user id. The AD team said it was changed and only has the old name for Exchange purposes. I have had her clear cookies and temp files as well as form data in IE. Any ideas on why this is happenning and what I can do to resolve?
Oh my app uses windows authentication for security.
Has her login ID actually changed, or did the AD folks just change the name for the account. The login account is a separate thing - the Name property on a WindowsIdentity is the account name, not the user's forename/surname.
I have a site , and I want to prevent my users to log in to site for more that one sessions.For example , if a user logged into my site in computer A , I prevent to try to log in to site in computer B (since it is logged in to site in a computer and did not log out)
Is there any solution ?
I have 3 ideas(actually they are bad idea and i am looking for better idea)
1 - use Session State
2 - use Application State
3 - use who2 table in sql server
UPDATE : I have my user management approach , and i did not use ASP Membership
The idea is that you have to keep track somewhere on your server (application state, database, ...) a list of authenticated users. When a user signs-in you will first look if he is present in this list. If he is refuse the sign in. If he is not add him to this list and allow him to login. Everytime the user performs some action on your site update the this list with the date when he performed this action. When signing in if the user is present in the list and the date when he lastly performed an action on your site is older than a treshold date you have defined you could allow sign in.
In our application, we have a need for a user to "impersonate" a different user. Think of it as a hierarchy -- Bob is above Frank in a hierarchy. Bob is logged in, and he needs to do things in the system for a short time as Frank. So, we have given Bob a list of users that report to him, and an impersonate link. He clicks on this link, and, behind the scenes, I log Bob out, and log in as Frank. I also set a session variable that tells me that really Bob is they guy who is the user. Also, Bob (acting as Frank now) has a nice little link at the top of every page that says "Stop Impersonation."
In addition, when Bob is impersonating Frank, Bob is restricted from doing some things, like changing Frank's password.
This was working great, until we encountered a situation where, if the session (I think -- getting confused here) gets destroyed (such as when I copy up new code and dlls to the live site), then when Bob clicks on "Stop Impersonation" he gets redirected to the default page, and is still logged in as Frank, but without the Impersonation session variable. So, now Bob really is logged in as Frank, and can change Frank's password (among other things).
How is it that a session variable (Impersonation) gets destroyed, but I guess the session is still hanging around, because it doesn't make the user log in again?
This is a somewhat serious bug for how our system works (bug in our code, I'm sure, not in .Net). Does anyone have any suggestions for a solution for this?
We are using ASP.Net c#, aspnet membership services, .net 3.5, forms auth...not sure what else you need to know.
EDIT: Updated information. Looks like when "something" happens, for instance, when I recompile some dlls and copy them to the webserver, the session gets dumped. Or, rather, the variables in the session get dumped. The session id stays the same. I do get to check for Session.IsNewSession and it returns true, even though the id is the same as it was before.
Just like Utaal mentioned, Membership Services is separate from Session, so it's forms auth token is still hanging around in the browser, but my session variable telling me that that isn't really the user who is controlling the browser isn't there anymore.
EDIT: Sky, here is what I'm doing to authenticate a user. I can't figure out where I would insert a ticket into this flow:
if (Membership.ValidateUser(txtUserName.Text, txtPassword.Text))
FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
So, where can I slip in a ticket object and set my own information?
Matt,
Use the UserData slot on the forms ticket to store the impersonation information. That is what it is for.
Then your info will not get lost with the session.
If you would like a simple example of creating your own ticket, amongst other things, check this. You may want to focus on the login page and the tickethelper class.
I think your problem is due to the fact that Forms Authentication and Session are two different things and are not interconnected: both of them (usually) use cookies but Forms Authentication stores the encrypted logged-in user directly in the cookie while Session stores information in-process (even if you can change this behaviour) and uses a cookie with a session identifier to retrieve it.
So, when your session information gets lost (or session expires) it isn't really still hanging around (except for the invalid session cookie on the user's pc). On the other hand the Forms Authentication cookie is still valid (ASP.NET decrypts it and authenticates the user for the request).
A possible solution is to detect the creation of a new session (using HttpSessionState.IsNewSession MSDN) and sign out the user (using FormsAuthentication). You can then redirect user to login page.
I have users with accounts on Site A. Site A has been around a long time, and it's expensive (but not impossible) to change its code.
Site B (I'm working on it now!) hosts a brand new web app for the customers of Site A. The Site B app has a list of the usernames from Site A, and maintains preferences and other information about each of those users that pertains to their usage of Site B. Site A and B are different platforms. I think Site A is coldfusion, and Site B is ASP.NET MVC.
I want users to be able to click a link in Site A that logs them into the app on Site B. I was thinking it might work like this:
0) If user tries to go straight to Site B, they just get redirected to Site A to be authenticated.
1) User logs into Site A.
2) Once logged into Site A, they can click a link that takes them to Site B. I was thinking I would do an HTTP Post from Site A to Site B with the username, so Site B knows who is logging in and how to render their pages based on their preferences.
Of course, I don't want any Joe Schmoe to be able to do an HTTP POST to Site B with a username and get to be logged in as that user.
So I was wondering if, using certificates or something, I could make it so Site B is able to know for certain that the POST really came from Site A. Do I need / Can I use certificates for this? Maybe Site A can somehow "sign" its post so Site B can know for sure the post came from Site A?
Or could just a password be enough, where Site A posts a password over SSL along with the username that only Site B knows?
I'm also open to the idea of Site A posting the username and a GUID to Site B, which Site B would then "ask" Site A via a web service if this is indeed a recent and valid GUID that did in fact originate at Site A, but that seems like a trip I can eliminate.
I hope that is descriptive enough. Please feel free to have me explain more. Thank you for your help. :)
Another option would be..
User signs into site A.
Site A creates a guid that is associated with this user but will expire in 5 seconds or some short time frame.
The user is redirected to siteB?UserID=SomId&ConfirmationId=Some Guid
Site B calls a web service on Site A, passing the UserID and Guid and checks to see if this is a valid redirect. (The web service just returns a true or a false).
This solves your issue of trust, as site B is explicitly querying site A, so site B KNOWS that it is using Site A for authentication, and not just blindly trusting that the confirmation is coming from a redirect from site A.
Also, a Guid is unique enough that it's unlikely to be guessed by hackers, and finally, the expiration makes it so that if a hacker DOES guess the guid, it will likely have expired by the time it's been guessed.
Of course, you'll want this all done over SSL.