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

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

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:

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