My application uses a Angular frontend paired with a C# backend.
For determining who's currently sitting in front of the pc, I use C#/ASP.NET's Current.User.Identity .
Now, there is not a coding issue, my problem is that windows keeps handing out the wrong Identity. This happens since yesterday. My website keeps telling me I am IISAdmin, instead of my User Account that I am using right now.
I am guessing this probably stands in some relation to me adding a couple of network shares (quick access to the servers) using the credentials of IISAdmin and ticking the checkbox "Save Credentials".
Normally when I deploy patches I just connect to the server manually via explorer, and enter the credentials by hand. I have done this multiple times, this has never been an issue.
This is where it gets a little odd. I have tried starting Chrome explicitly as my User, and it just merged the window into the existing Chrome window I had already. Opened my web-app, IISAdmin.
I closed Chrome entirely, started it explicitly as my user again, IISAdmin.
Starting Chrome as a dummy account that I have access to, Chrome correctly opens a new Chrome window, and User.Identity confirms that I am logged in as said Dummy.
Internet Explorer behaves exactly the same way, so this is not browser-specific.
Even after a complete reboot this keeps remaining an issue. The network shares were removed after the restart, I am assuming they were temporary.
Windows should hand out my standard issue user account auth, not a highly powered super admin that's just saved somewhere.
After talking to some colleagues, they pointed me towards the solution.
If this happens to you:
Go to System Control / Credential Manager / Windows Credentials
(Golden Safe)
Delete the conflicting credentials
I was not aware of this at first, but when you create a network share and save the credentials, it saves them here.
What I didn't expect was that windows maps the file path to the server to the server's actual IP / DNS adress.
So whenever you connect to said server, Windows uses the saved creds it has, and because of the way Kerberos works, your existing token just get's handed around.
Hence making things a little mushy, even if you explicitly start Chrome as your normal user.
Related
I'm developing a dropbox asp.net application, and it's working at least in localhost mode. But I'm facing a problem that I hope is only during localhost testing and won't (CAN NOT) occur in production. It's a bit difficult to explain so I will describe it in steps.
1) The browser is not running and I start the "logged in membership target page" in Debugger. It asks dropbox for login and permission. At this time, in my Oauth derived class, I store my drop box object with access token and secret in a session variable.
2) In my actual "logged in" page, I extract the object from the session and start using dropbox and it works fine.
3) Now suppose I stop debugging from Visual Studio 2012. Make some modifications to the code. Now I start again. This time the browser is already logged in to dropbox and the target page is displayed logged in. I see no "Allow" prompt from dropbox. But there is no session variable now to extract my drop box object because this is a new session. But for dropbox it is the already logged in session.
I want to confirm that this situation can only occur during localhost running and can not occur in real production app because it will always go from a web site in the browser which will have its own session. Or can it occur? What is the solution in that case.
Another doubt is, why doesn't dropbox ask for Allow prompt next time if the browser is open but the app is starting a new session. It must be getting the same access token and secret from somewhere. From where?
I think I found a workable solution. If I find that the session has been lost, I execute the following code and it logs off the user. Even if the situation might occur only in my local testing, this takes care of it.
FormsAuthentication.SignOut();
Response.Redirect("/");
return;
I'm afraid I cannot get through this problem on my own. It is weird that this issue seems to be unique for my installation.
On my WordPress-based website users are having trouble with the login, especially when using their mobile phones to authenticate: they are being logged out (even when checking "Remember me") and will have to re-enter their credentials (after which they're logged out again). From what I figured, it is most likely the fact that their respective mobile Internet Service Providers dynamically assign new IP addresses to their devices all the time, causing the authentication to fail.
When I'm using my desktop to login, everything will work just fine. However, say, I have successfully logged in to the site with Google Chrome, and I open an instance of Mozilla Firefox (or any other browser) to log in simultaneously, Chrome's user "session" will be shut down immediately (I know that because an asynchronous script is requesting whether or not the user is logged in and it prompts me to log in once I sign in using the other browser). Therefore I believe that the whole WordPress authentication has got something to do with the user agent, too.
Albeit I highly appreciate the extra amount of security provided by automatically voiding a running session when accessing the site from a different IP or browser, my users do not. Even for myself it is remarkably cumbersome, using three different machines plus tablet and phone to access the site from any possible place (eventually I stopped bothering to log in and just waited to get home).
Since WordPress authentication uses cookies, I looked into how these are generated. The wp_generate_auth_cookie() method uses the user name, parts of their hashed password, the expiration time and a salt (a constant salt defined in wp-config.php), but neither does it use the IP address nor the user agent.
I literally searched the whole WordPress folder for "user agent" or "IP address" occurrences but there is no login-related script containing the terms (merely a handful of plugins that don't affect the user session at all).
That puzzles me. How does WordPress even realize that I am logged in with a different browser / computer if it doesn't store that data with the authentication cookie? And where does the check happen that logs me and my users out?
Do you have any further ideas on how to troubleshoot the issue?
Thank you very much in advance!!
Harti
Cookies are stored by browsers and different browsers on the same machine don't share that storage. Thus when you login with Chrome, WP sends a login cookie to Chrome, starting a new session. When you then access the site with Firefox, FF doesn't have a login cookie so WP prompts you to login and then sends a login cookie to FF, also starting a new session. The next time you access the site with Chrome, it gets Chrome's login cookie, which doesn't match the last one sent out that's associated with your username, so everything starts all over again.
This doesn't directly explain the problem with mobile devices; it sounds like for some reason they aren't storing the cookies properly.
I have a diagnostic web application hosted in IIS7 that has Windows Authentication enabled and Anonymous auth disabled. This application generated some kind of a report where it includes information about what kind of authentication was used to view the site. Every time I browse to this site I get a message that I connected using Anonymous authentication which for me is unbelievable. The report works fine (tested on other machine) and the fact is that I do not get a credentials popup. How is this possible and how can I fix this?
First, i'm not knocking your diagnostic application, but it may be worth looking at the IIS logs (or indeed switching them on for your site) to see what IIS thinks is going on. If you're not familiar with IIS logs, I'd suggest writing them in Microsoft format (at least while you're sorting this problem). One of the key fields you get is the user id. If you really are hitting the pages anonymously, this id will be the id you configured to field anonymous requests. Otherwise, it will normally be the calling user's id (at least in a simple scenario).
Second, how many sites are you running? Are you sure you're going in through the expected site? Or maybe you're hitting the default site instead?
Third, bear in mind that authentication can be set at the site level but anso at the page level. Are you sure one isn't overriding the other?
Is there a way to get the logged in user from a vb.net web application? IE, if someone logged in as "foo"/"bar" on their local machine accesses the site, I need code to get me "foo"/"bar". This is for a passthrough on our intranet, where everyone uses the same Active Directory.
Essentially, I need to harvest the username of the logged in user and check it against our ActiveDirectory instance. If that fails, I need to check for Request variables and check those (that part is fairly easy). Then if THAT fails, I need to show a login screen (I also have a handle on this).
I've already come across and discarded a couple solutions for the part I'm having trouble with:
request.serverVariables("LOGON_USER") - This only works if you have anonymous access turned off in IIS, and that must be on to use forms authentication (which I'm using).
http://www.thescarms.com/dotnet/IsInRole.aspx - This solution does not seem to work for some reason. I suspect the line AppDomain.CurrentDomain.SetPrincipalPolicy( Principal.PrincipalPolicy.WindowsPrincipal) is the issue, but the meaning of this line is buried so far I can't figure out what it's actually trying to do.
HttpRequest.LogonUserIdentity?
if you're using Forms Authentication, have you tried System.Web.HttpContext.Current.User.Identity.Name?
The web browser will not send the user's local credentials to the web server unless two things are true:
The web server asks for them (i.e. Anonymous Access is disabled, and Windows Integrated Authentication is enabled).
The web browser has been configured to send local credentials if asked (an Internet Explorer option, available in FireFox via plugin, not sure about other browsers). If the browser has not been configured to send the information and the web server asks, the user will be prompted within a pop-up login screen.
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.