Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm not entirely sure this belongs on I also considered and, 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, 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 instead of However, if this was wrong, it would presumably affect all users?

share|improve this question
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? – Daniel Beck Jan 4 '12 at 11:25
I've verified the domain on the cookies which are returned for both domains, and they match the correct domain in each case. – Richard Fawcett Jan 4 '12 at 11:30
Do you have some kind of load balancer or redirection mechanism where people with cookies from D1 end up on D2? – Daniel Beck Jan 4 '12 at 11:35
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. – Richard Fawcett Jan 4 '12 at 11:52
The likely suspect is the monster that is AVG Internet Security 2012. – Ramhound Jan 4 '12 at 14:15
up vote 2 down vote accepted

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 and at a different time as

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" />

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

share|improve this answer

Any ideas what is causing login to fail?


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


  • Check your Cookie settings for the relevant Security Zone (Internet, Local, Trusted, Restricted).
    In IE8: Tools, Internet Options, Privacy, Sites
    Maybe 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/

  • 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 may be blocked in one of the other zones that would normally apply to

share|improve this answer
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 Jan 4 '12 at 11:33
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? – Richard Fawcett Jan 6 '12 at 11:38
@RichardFawcett: See updated Answer. – RedGrittyBrick Jan 6 '12 at 12:02

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

share|improve this answer
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! – Richard Fawcett Apr 12 '12 at 14:34

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.