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?

Solution 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!

Solution 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.

Solution 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

Comments

[HikeMike]

Does Internet Explorer have an option that prevents cookies for third party sites (e.g. your non-working login server sets a cookie for the working server with a different host name) or some other privacy feature that might interfere here?

[Richard Fawcett]

I've verified the domain on the cookies which are returned for both domains, and they match the correct domain in each case.

[HikeMike]

Do you have some kind of load balancer or redirection mechanism where people with cookies from D1 end up on D2?

[Richard Fawcett]

No, single server, so decryption of the forms authentication cookie / availability of session data should not be an issue. Should probably have mentioned this is an ASP.NET web application. Thanks for your help so far.

[Ramhound]

The likely suspect is the monster that is AVG Internet Security 2012.

[JdeBP]

Edit your question to tell everyone what the difference is between the cookies received in step 3 and the cookies sent in step 4.

[Richard Fawcett]

Indeed they are consistent. I've double (treble!) checked the domains set on the returned cookies, and in all cases, they match the hostname that the browser requested. Remember also that this isn't affecting all users. I'm going to investigate the cookies the browser sends on the redirect in step 4, and ensuring the auth cookie is present, and matches the one returned in step 3.

[Richard Fawcett]

As you can now see from the question, I've done some more diagnostics around cookies. Cookies are the issue, so have an upvote for putting me on the right track. The cookie sent to the client during step 3 is not returned to the server on subsequent requests. Any ideas?

[user5249203]

@RichardFawcett: See updated Answer.

[Richard Fawcett]

Thanks for you answer - in my case, this wasn't the problem (we had the expiration set to be a couple of days anyway, rather than 20 minutes). However, I'm sure it could help some people struggling with this!

[tschale]

Did you experience any problems or side effects with renaming the authentication cookie?

[Richard Fawcett]

@tschale No, everything was fine. The cookie name is designed to be configurable, so everything just worked. Of course, it logged all existing users out when it was changed.