3

I initially asked this question, which shows that I see MVC errors of missing POST values. I was unable to reproduce - I still can't reproduce it on demand, but I did get the error myself on IE11, and I got a clue...

I have an application in IIS7.5 running with Basic authentication only. I look in Fiddler, and normally all transactions have Authorization: Basic xxxxx as expected. The body contains POST values as expected, and Content-Length is correct.

When I experienced this problem, I found that every single request (GETs and POSTs, including static content) was now showing Authorization: Negotiate xxxxx in Fiddler, with an empty body and zero Content-Length, even when I submitted a POST object via jQuery AJAX, and IE's dev tools shows the real POST body (which of course means IE is lying - not the first time). It gets a 401 response, and then a new request occurs with Basic, but also with an empty POST body, which means ASP.NET throws an error about missing parameter values.

Other web applications on the same top-level domain do use Windows authentication instead of Basic, and my suspicion is that the user goes to one of these sites, and IE becomes confused and thinks that my application should use Windows authentication as well - but I can't reproduce that every time. I have reproduced it twice, but out of a dozen or so times of doing the same thing over and over, so I'm not finding a way to make it reproduce every time.

I don't know why the POST body would get emptied, even if it does switch over and try to do WinAuth instead of basic - but that's when the problem occurs, so I'm sure it's related.

Any ideas on how to prevent IE from getting confused and using Negotiate, or at least how to detect and gracefully handle this on the server? I've only seen it in IE, but I can't be sure it's IE-only.

Here's what a normal POST looks like:

Normal post

Then after the problem starts occurring, the exact same POST looks like:

Bad post

EDIT

Here's an interesting edit - I just saw a new symptom. This time, all GET requests are coming in with no Authorization header at all, and the response comes back with a 401 for basic, and the GET is re-done properly with basic. But the POSTs are going through normally, with basic on the first try. I don't know what started this happening, but it's a similar symptom of the same problem.

Community
  • 1
  • 1
Joe Enos
  • 39,478
  • 11
  • 80
  • 136
  • Your problem resembles an IE attempt to login to AD. Such attempts can hijack your request as the browser bounces arround trying to "negotiate" the authorization process. If your controller or action uses a `[Authorize]` attribute, that would be part of the issue? Are you on an intranet? Do you know if you have tight group policies (assuming you are on AD on site)? – Dave Alperovich Jul 07 '16 at 05:00
  • I'm not using the `Authorize` attribute anywhere - all of our security is done manually with code. Some of our users are internal and IE thinks it's an intranet site, apparently based on the domain name - but at least one of the users experiencing this is not internal, so their browser would not think it's intranet. They do log in using their AD credentials over basic authentication, but I don't know anything about how the AD is set up. – Joe Enos Jul 07 '16 at 14:53
  • I think this **IS** your problem. There is a way to turn off auto authentication in IE (gotta look that up), and there is a way to add a domain to your trusted sites. I'll look these up when I get the chance, but you see how this is probably going to require a client by client local change :( – Dave Alperovich Jul 07 '16 at 15:01
  • I found out that one of the users uses Chrome, and another one uses Firefox. So it apparently happens on any browser. I requested screenshots from the users on their settings, so I'll see if anything weird shows up there. – Joe Enos Jul 08 '16 at 18:51
  • makes me wonder, but I would still look at group policy on the AD. Seems the most likely. Packet loss is best explained by a redirect and `Authorization: Negotiate` is clear case of it. Look at the last answer on this post, specifically turning on Anonymous Auth in IIS http://stackoverflow.com/questions/13023519/how-to-remove-unwanted-www-authenticate-headers – Dave Alperovich Jul 09 '16 at 18:51
  • May be a dumb question, but I assume that Windows Authentication is disabled for the site in IIS, correct? I also second the comment about looking at the Anonymous auth in IIS – Justin Patten Jul 13 '16 at 15:00
  • @JustinPatten Basic is Enabled in IIS, and everything else is Disabled. I tried enabling Anonymous in addition to Basic - but of course the user then doesn't input their credentials, and the app rejects them as unauthenticated. This uses basic authentication against the domain, so there is no "login" page. – Joe Enos Jul 13 '16 at 15:03
  • Do you have any network traces of the 401 response that causes the browser to respond with basic versus negotiate? Usually, the server will indicate what type of authentication it supports, e.g. `WWW-Authenticate: Negotiate WWW-Authenticate: Basic` in the reply header. – Justin Patten Jul 13 '16 at 15:09
  • @JustinPatten Thanks. Using Fiddler when everything works properly: My very first request goes in with no auth header, and gets a 401 with `WWW-Authenticate: Basic realm="mydomain"`. Then I log in, and the next request and all subsequent requests have `Authorization: Basic xxxxxx` and are successful, and the responses don't have auth headers. When there's a problem, I get the behavior detailed in the above question. The problem seems to start with the browser, rather than the server, since it seems the browser wants to use Negotiate even though the server never tells it to. – Joe Enos Jul 13 '16 at 15:19
  • So in the cases that the browser sends negotiate, the 401 response only includes basic as an option? That seems odd if true – Justin Patten Jul 13 '16 at 15:24
  • I don't know 100% of the time, but when I saw it (I can't reproduce on demand), the first Negotiate request happened on an AJAX POST request - so it was not in response to a previous response to a `WWW-Authenticate: Negotiate` response, at least not from this app. – Joe Enos Jul 13 '16 at 16:14
  • Joe, have you resolved this problem. We are seeing this problem in IE (11) only, but FF and chrome are fine. We are a little different in that we have an angular front end talking to a spring back end. We support basic and NTLM. The user is authenticated with a JSESSION cookie and is running along just fine. Randomly we get the Negotiate with Kerberos and in IE, just like you found, it shows the body, but does not send it when looking in fiddler. I have seen tons of IE6 posts about this, but none recent. – Chewy Oct 21 '16 at 15:47
  • @Chewy No, we never resolved it. It only happens to a couple users, and best we can tell, the browser ends up correcting it and saving the data properly, so the only damage seems to be the server logging these errors. We considered switching over from Basic to Digest authentication, but of course we had [other issues](http://stackoverflow.com/questions/39576387/chrome-requires-multiple-authentication-attempts-with-digest-authentication) and don't have the time to fully troubleshoot either issue. – Joe Enos Oct 21 '16 at 15:55
  • That's a bummer - for us it we get the message and on methods (most) that are POST, the body is required, so this gives us a 500 error back to the client. Thanks for the feedback. – Chewy Oct 24 '16 at 14:03
  • I posted another question earlier on my particular problem and did end up solving it. http://stackoverflow.com/questions/40918017/ie-sends-empty-post-body-randomly-while-using-ntlm-using-angular-to-spring/41004109#41004109 – Chewy Dec 06 '16 at 20:20
  • @Chewy That looks extremely interesting, and might just be exactly what I'm facing. Thank you for linking to it. – Joe Enos Dec 07 '16 at 14:13

0 Answers0