Why won't IE let users login to a website unless in In Private mode?

Question

I'm not entirely sure this belongs on SuperUser.com. I also considered ServerFault.com and StackOverflow.com, but on balance, I think it should belong here?

We host a website which has the same code responding to multiple domain names. On 28th December (without any changes deployed to the website) a percentage of users suddenly could not login, and the blank login page was just rendered again even when the correct credentials were entered. The issue is still ongoing.

After remote controlling an affected user's PC, we've found the following:

• The issue affects Internet Explorer 9.
• The user can login from the same machine on Chrome.
• The user can login from an In Private browser session using IE9.
• The user can login if the website is added to the Trusted Sites security zone.
• The user can NOT login from an IE session in safe mode (started with iexplore -extoff).
• Only one hostname that the website responds to prevents login, the same user account on the other hostname works fine (note that this is identical code and database running server side), even though that site is not in trusted sites zone.

Series of HTTP requests in the failure case:

1. GET request to protected page, returns a 302 FOUND response to login page.
2. GET request to login page.
3. POST to login page, containing credentials, returns redirect to protected page.
4. GET request to protected page... for some reason auth fails and browser is redirected to login page, as in step 1.

Other information:

• Operating system is Windows 7 Ultimate Edition.
• AV system is AVG Internet Security 2012.

I can think of lots of things that could be going wrong, but in every case, one of the findings above is incompatible with the theory.

Any ideas what is causing login to fail?

Update 06-Jan-2012

Enhanced logging has shown that the .ASPXAUTH cookie is being set in step 3. Its expiry date is 28 days in the future, its path is /, the domain is mysite.com, and its value is an encrypted forms ticket, as expected.

However, the cookie is not being received by the web server during step 4. Other cookies are being presented to the server during step 4, it's just this one that is missing.

I've seen that cookies are usually set with a domain starting with a period, but mine isn't. Should it be .mysite.com instead of mysite.com? However, if this was wrong, it would presumably affect all users?

Answer 1

My analysis in my update regarding the cookie not being returned to the server was incorrect. At some point before my logging code ran, the cookie was being expunged from the cookie collection server-side.

Using Wireshark, I determined that actually, two copies of the .ASPXAUTH cookie were being sent to the server, one was invalid and one valid. Technically, the order of cookies is non-deterministic, so I think it was affecting people whose browsers were sending an invalid cookie first... ASP.NET just didn't consider the second, valid cookie at all.

As mentioned above, the cookie in question was .ASPXAUTH which is the default name for .NET's authentication cookie. We believe two copies of it existed as it had perhaps been sent under a different domain in the past (once as www.mysite.com and at a different time as .mysite.com).

The easiest solution, which worked perfectly, was to change the name of the authentication cookie, by setting the following in Web.config:

<authentication mode="Forms">
    <forms name="SOMEOTHERCOOKIENAME" />
</authentication>

Then, just make sure that the new cookie is only ever sent with a single value which will match a given request!

Answer 2

Any ideas what is causing login to fail?

Cookies.

• Private mode probably has a separate set of cookies (otherwise it would hardly be private)
• Different Browsers have separate cookies
• Cookies are usually specific to website domain name.

All these are consistent with your problem description.

---

Update:

• Check your Cookie settings for the relevant Security Zone (Internet, Local, Trusted, Restricted).
  In IE8: Tools, Internet Options, Privacy, Sites
  Maybe mysite.com is blocked in the relevant zone?

• Check your actual cookies
  In IE8: Tools, Internet Options, General, Browsing History, Settings, View Files
  Look for cookie:username/mysite.com/

• Check for non-default Cookie Handling Settings
  They might block "third-party" cookies (if that applies)
  The might choose to be prompted to accept/reject new cookies.

You say "The user can login if the website is added to the Trusted Sites security zone." This implies that mysite.com may be blocked in one of the other zones that would normally apply to mysite.com.

Answer 3

I had something very similar, the ASP.NET authentication cookie was not being set in IE or Chrome, strangely though it was in Firefox (I've still no explanation for why that is).

What turned out to be the problem for me was that the server time was incorrect, it was 30 minutes in the past. So at 9:50 when I logged into the site the server set the expiration time of the cookie at 10:10 but my computer had the time as 10:20, so the cookie had already expired. Updating the time on the server fixed the problem for me

Answer 4

In the Explorer Internet Options, General, Browsing History, Settings, You can try to change "check new version..." setting from "Automatically" (3rd choice) to "Every visit..." (1st choice).

I've had a nearly identical problem and this workaround worked. Never found what the problem was...

Also (but I don't think it's your case), check for clock difference between server and clients.