Asp.net forms authentication cookie not honoring timeout with IIS7

26
votes

Authentication cookies seem to timeout after a short period of time (a day or so). I am using Forms Authentication and have the timeout="10080" with slidingExpiration="false" in the web.config. With that setting, the cookie should expire roughly 7 days after the user is successfully authenticated.

This worked as advertised with IIS6, but when I moved the site to IIS7, the cookie expires much quicker. I've confirmed this behavior on multiple machines with IE and Firefox, leading me to believe it's an IIS7 setting.

Is there a hidden setting that is IIS7 specific related to authentication? All other authentication types are disabled for the website, except for anonymous user tracking.

5
asp.netauthenticationiis-7cookiesforms-authentication
Have you used the developer tools in FireFox to look at the cookie data, and see what the Expiration date is? – Josh Pearce
Yes, and the cookie is set to expire as the web.config is configured. For some reason, though, the cookie expires early and I need to re-login. As I mentioned, this happens on multiple computers w/ multiple browsers. – Jim Geurts
probably the cookie doesn't expire, but some other thing kills it – Omu
Out of interest: are you using session state? If not, what happens if you do (by putting something, anything, into session state when a session starts)? There seem to be some interesting bugs in that area which are solved by ensuring session state is initialized. – Jeremy McGee
No, it's still a mystery. I lost 300 rep points for nothing thus far... – Jim Geurts

5 Answers

43
votes

The authentication cookie is encrypted using the machineKey value from the local web.config or the global machine.config. If no such key is explicitly set, a key will be automatically generated, but it is not persisted to disk – hence, it will change whenever the application is restarted or "recycled" due to inactivity, and a new key will be created on the next hit.

Resolving the problem is as easy as adding a <machineKey> configuration section to web.config, or possibly (preferably?) to the machine.config on the server (untested):

<system.web>
  ...
  <machineKey 
    validationKey="..."
    decryptionKey="..."
    validation="SHA1"
    decryption="AES"/>
  ...
</system.web>

Google generate random machinekey for sites that can generate this section for you. If your application deals with confidential information, you might want to create the keys yourself, though.

0
votes

My understanding is that cookies are expired by the consuming party - the browser, which means that IIS has no say in this

0
votes

Set session state configured in IIS as In Process Use Cookies Time out = your required time Use hosting identity for impersonation

Also set EnableSessionState to true (which is default too)

And most importantly run the app pool in classic mode.

Hope your problem will solve.

0
votes

First of all i must say that these "guidelines" are generic and not iis-7 exclusive. In web.config under <system.web> you either have <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (which requires the ASP.NET Session State Server service running on localhost) or <sessionState mode="InProc" timeout="130" cookieless="false"/>. The main difference is that in InProc that session state data are placed in the application process itself. In the other setting a different service is doing the storage, and you application just polls it to get the required data. Having used both (as well as sql-server session state mode) the InProc is the least reliable but the fastest. The Sql-server is the most reliable and the slowest and the StateServer mode is somewhere in the middle being unreliable only in the case of a power/system failure. Having said that, i must say that for site with a low request count the performance penalty is negligible.

Now, my experience has shown that InProc is quite unpredictable on its stability; i used to have the same problem with you. I was able to extend the stability of the application by tweaking the settings of the application pool, i removed the problem altogether by switching to SessionState (which also allows to bring down the application and not lose session state data).

The reasons that you may suffer from application/session stability:

  1. IIS and application pooling. Each virtul directory of a website is assigned to an application pool (by default to "DefaultAppPool") which has a series of settings amongst which you define the interval that the process is "recycled" - and as such preserve system resources. If you don't change the settings the application may trigger one of the criteria for the process recycler, which means that your application is busted

  2. Antivirus. In a ASP.NET application if the web.config (and any child .config files the application depends on) file is touched the application is restarted. Now there are cases where an antivirus program may touch the web.config file (say once a day?) and as such the application is restarted and session data is lost.

  3. Bad configuration Specifically for Forms Authentication the time-related settings and behavior always where dependent on the web-session with the auth-session being under the web-session.

What i don't know is if the Forms Authentication module depends only on Session domain or if it also places data in the application domain as well. If the second is the case then you may have to disable all recycling settings in the Application Pool as well as checking again configuration/antivirus and who stores the session data.

0
votes

I recently had the same problem where my site was timing out every 20 minutes even though I set the session timeout to 2 hours. I found that it was because IIS worker process was timing out every 20 minutes: http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx