I'm having an interesting problem with FormsAuthentication on a client project I'm trying to assist with. Here's the problem:
The domain of web app was changed from .companyA.com to .companyB.com and I set up an IIS redirect to send anyone attempting to go to .companyA.com to .companyB.com. That works just fine.
Now I can't log in to the site. I did some digging and found out that there are authCookies being defined in the web.config, so I changed the the authCookie domains to match .companyB.com. I was still not able to log in.
I did some more digging and found that there was a SQL Reporting server set up. I changed the domain in the config files of the reporting server to match .companyB.com. Still can't log in.
For general purpose troubleshooting of this type of issue is there anywhere else I could look? I've just been put on this as a firefight so I've limited domain knowledge and can't open the solution in VS because the only VS they have available is too old for the solution.
EDIT: OK, after further digging, I found out that the user isn't authenticating wasn't the main issue. There was a problem with connecting to the reporting service DB and the exception was being swallowed up. Thankfully it showed up in the event viewer. Unfortunately this still leaves me with problems, I can't figure out why SQL won't authenticate me anymore and how changing domain names could possibly lead to that.
Debugging is really simple. Just get any http debugger (Fiddler will do) and run your application. You will see a list of requests. Just pay attention to the response which sets the auth cookie and then what happens in consecutive requests.
You will probably see that the cookie is set but is missing futher on. This could be because the cookie is issued for domain A (you will see the cookie's domain in the debugger) and the browser is not delivering it to the domain B (which the browser is supposed to do; it will never carry cookies to other domains).
Anyway, an http debugger will be a great help here.
Related
Our Platform is currently integrated to salesforce using the Partner WSDL.
A few days ago we've started getting this error while trying to login into the Sandbox environment:
INVALID_LOGIN: Invalid username, password, security token; or user locked out.
Initially we figured one of our API Users was locked out. However, after digging through our logs we noticed that the INVALID_LOGIN failure doesn't happen all the time. It seems to be occurring randomly. Some login attempts are successful. Some fail. What's stranger is that this is occurring across all of our dev servers and even across different client's API Users. However, we're not seeing this behavior on our production instance.
We have multiple development instances of our platform, but only a single production instance of our platform.
I haven't read any documentation that would suggest this, but currently my only guess is that we're seeing some issue with the same API user trying to login at roughly the same time from different dev instances causing the issue. Is that possible or could this be caused by a completely different issue I'm unaware of? I'm far from an SFDC expert. Is there some more useful debugging information I can get from SFDC?
I don't think this information would be that helpful, but in case there is some edge case I'm unaware of our platform is written using .NET / C#.
UPDATE: These login errors seemed to have stopped in the past 24 hours. No code / process change on our side. It would be nice to understand what the cause of this was. If anyone has insight on it.
With intermittent failures like this, particularly where no recent code changes have been made, a good starting point is http://trust.salesforce.com/trust/status/.
You can identify your pod from the URL, and then lookup any status issues for a recent date.
E.g.
Incidentally, the Salesforce StackExchange is a great place to ask Salesforce specific questions.
I have run into the wierdest issue, and I'm hoping some ASP.NET expert can give me some clues as to what is going on.
I have an ASP.NET Website running on IIS 6.0. On it, I have an .asmx webservice. In the .asmx webservice, I use System.IO.File.Exists() to check if a file exists on a network share. The site uses Impersonation.
Here's the massive kicker: If I set IIS to run the site using Basic Authentication, the File.Exists line returns True. If I set it to Integrated Windows Authentication, it returns False. I change nothing else, i can change back and forth and the exact same thing happens. I'm logging some information before the call to File.Exists() and indeed, both User.Identity.Name and System.Security.Principal.WindowsIdentity.GetCurrent().Name return the exact same name regardless of setting (my own account which obviously has access to the files I'm looking for).
I would post things I've tried but honestly, what can you try in this situation, where one setting which shouldn't affect the issue is the problem. I have tried turning impersonation off, and that also makes the File.Exists() call return True (which is blowing my mind since my own user has far higher permissions than the account running the appPool).
Any ideas what I can look into to get this issue resolved?
OK what is happening is that the server is not able to delegate the authentication. That is, it cannot act on behalf of the user to another server, only to itself.
Delegation is not a problem for Basic authentication because the server knows your password (because you told it as part of the basic authentication), so it can perform authentication to the remote computer.
If you are in an Active Directory/Kerberos environment, you must configure the server to be trusted for delegation. I have never had to do this so I am not sure exactly how, but it is a matter of configuration, not programming. You may have to configure the Server machine account, or the IIS identity or both, depending on your configuration.
See here for some references:
http://technet.microsoft.com/en-us/library/cc739474(v=WS.10).aspx
If you are not in a Kerberos environment, you must either use basic authentication, or get the password from the user in some other way, and call LogonUser yourself to impersonate the user. If Basic authentication is used or a clear-text password is used in any other way, you must of course use HTTPS/TLS for security.
I'm having a strange problem in a Silverlight Business Application that calls an external API. I'm sure it's just one line wrong or something. The API has one call that uses digest authentication and I handle that all myself. My code was working before, but then I began a transition to hosting the backend API and this front-end website on Azure and something must have changed. Now, before the request comes back to my code to handle, the browser is popping up a login dialog of its own. If I cancel out of that dialog, it moves on to my code and authenticates successfully.
It seems as if the browser is handling the request, noticing the 401 status code, and attempting to resolve it itself. But I do register the ClientHttp factory for the http:// prefix as suggested, and the request type that is created is a ClientHttpWebRequest. Like I said, this was all working about a week ago using the same authentication code and everything, so I'm sure it's just going to be some setting. But I'm not sure where that could be and I haven't found anyone else with this problem.
Curiously, when I publish the ASP project to an Azure website, it all looks and acts as expected, but the login doesn't even pop up the dialog. It simply doesn't do anything when I click "login." So that part looks like maybe an unhandled exception is being thrown then it's not telling me about it, but I'm not sure why that would be the case on Azure but not IIS Express.
Basically, I just don't want that dialog coming up. I am inclined to assume that the same problem that's causing that is whatever is making the Azure-hosted version not do anything.
I've done a fair bit of searching and found this question, "How can I supress the browser's authentication dialog?" which seems to be the same issue, but as I stated a few times, this was working just last week. I do have full control of the API and this site, so I could alter some things to make it suppress HTTP statuses and simply return a 200 with details in the content as a substitute, but I'd rather avoid that extra layer of complexity if it really is something simple, as I imagine it is.
After some fiddling, it seems the best way to handle this error is simply to use the WebRequest.Credentials property and populate it, rather than forming my Digest authorization header myself. It isn't exactly what I was going for, but it will do for now. I still don't know why this stopped working in the first place. But what fun is programming if everything goes according to plan?
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
This certainly is a strange one...
I have an ASP.net 4.0, C# website that has a login page using FormsAuthentication to handle user access. There's also code throughout the site that boots the user back to the login page whenever a session times out or something else that requires them to login again happens. This is all really basic stuff that I've done about a dozen times before.
I know this whole process is working, because I've been able to login to the site running through VS2010 on EVERY browser I tried. It also works perfectly fine when it's sitting on the development server using Chrome, Firefox, Safari (Mac), and two Cellphone browsers. The only thing I've had a problem with is Internet Explorer.
Now, this one is a bit hard to debug considering it works in IE locally but not on the server. The fact that it also works in other browsers on the server is also sort of ruling out a server configuration issue.
What I did to try and figure out where it could be going wrong was add a query string to my FormsAuthentication.RedirectToLogin("WhateverPage=WhateverSectionOfCode"); line to try and solve this. The problem is that when I run the site in IE, it never appends that Query String, which leads me to believe that it never hits any of those "RedirectToLogin" lines.
I know it authenticates, because the code that updates the Last Login timestamp in the database only fires if the user is authenticated. It looks as if the "RedirectFromLogin" line does go out and find the proper entry in the web.config...and it might actually be redirecting me, but even if it does, it always bounces me back to the login screen.
I've been through all of the really basic ID-10T errors (heh) that could possibly be causing this: Heightened security settings, disabled cookies, etc., but I'm getting the same results on multiple machines.
I'm really sort of stumped as to what to check for next. I've already had two other sets of eyes on the code, but they couldn't come up with any reason as to why this was happening. If anyone has any suggestions as to what could be happening, I'd love to hear them.
Thanks!
i think it is something about cookies..
did you set the domain attribute in the web.config?
<authentication mode="Forms">
<forms loginUrl="~/login.aspx" name="cookiename" domain="domain.com" cookieless="UseCookies" slidingExpiration="true" timeout="60"/>
</authentication>
forms Element for authentication (ASP.NET Settings Schema)
I know this ticket is a bit old, but apparently IE can't set forms authentication on a domain with an underscore in the name. So if the issue appeared on a development server that was, say Dev_XP, then IE won't be able to set an authentication cookie.
That's what happened with me. Here's the link: http://orwin.ca/2012/02/09/formsauthentication-setauthcookie-not-working-in-ie-but-works-in-other-browsers/
This is the KB artical that outlines the issue http://support.microsoft.com/kb/316112
I'm having same issue, but with all other browsers except Chrome.
The strange thing is that when all these browser are tried locally (in same computer where service is running), everything works well.
When I'm connecting remotely - only Chrome works. Firefox and IE are redirecting me back to login page every time, though user is authenticated - same as yours, in database logon timestamp updated.
But I have also developer server, located in the other network, connection to this network takes less time, and here are all three browsers works OK too.
So I think that the problem is in IIS settings, which might be different on real vs developer server, or it might be a problem in Redirect and thread, which creates session. I found some interesting topic about this. It's about ASP WebForms though. See my question on stakoverflow. And please, let me know if you solve this problem!