Question

(See question below for more context):

Are there any situations in which

<machineKey
      validationKey="AutoGenerate,IsolateApps"
      decryptionKey="AutoGenerate,IsolateApps"/>

in web.config would fail to AutoGenerate a new machineKey on App Pool recycle? This is the behavior I'm seeing...

I'm using standard ASP.NET FormsAuthentication in an MVC app. If I log a user in using FormsAuthentication.GetAuthCookie and don't use a persistent cookie (relying on the browser's session to remember my authorized state), I would expect recycling the IIS App Pool to invalidate the session's knowledge of this cookie...and thus logout all users who don't have persistent cookies.

This DOES happen on one of my IIS installs (XP), but on a different IIS configuration (Server 2K3) the FormsAuthentication cookie (under the standard name ".ASPXAUTH") remains valid and continues to authorize the user.

Does anyone know why this is happening or what configuration controls this behavior?

Obviously recycling the app pool has no control over whether or not the browser still sends the .ASPXAUTH cookie (as long as I haven't closed my browser and the cookie hasn't expired).

In the case of the IIS install that properly denies authentication after a recycle, I can see the incoming cookie in Request.Cookies during the Application_BeginRequest event...but once control moves to the next event available in Global.asax.cs (Application_AuthenticateRequest), the cookie has been removed from the Request.Cookies collection.

Why does this not happen for both IIS/ASP.NET configurations?

In case this isn't clear, a simpler way of forming the question is:

Why does HttpContext.Current.Request.Cookies[".ASPXAUTH"] change from {System.Web.HttpCookie} to null when I step, in a single request, from Application_BeginRequest to Application_AuthenticateRequest?

More debugging information:

If I attach the following code to Global.asax.cs's FormsAuthentication_OnAuthenticate event...

var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
    var val = cookie.Value;
    try
    {
        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
    }
    catch (Exception)
    {
    }
}

...then during a request before I recycle the IIS App Pool, no exception will be caught. After recycling the IIS App Pool, when the exact same .ASPXAUTH cookie is sent from the browser, a Cryptographic exception is caught ("Padding is invalid and cannot be removed.")

Why is this?

Is one configured to use the ASP.NET State Service to store the session instead of inproc? — devstuff, Jul 10 '09 at 14:25
Good thought -- no, they're both using InProc, unfortunately. — kamens, Jul 10 '09 at 14:34

score 3 · Answer 1 · edited Jun 20 '20 at 09:12

Our application is stateless (no session required), yet we had a situation where an app pool recycle caused invalidation of all machinekey-encrypted cookies on a server environment (above described issue). This was caused because the machinekey changes with every recycle, which should not be the case.

The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA)

https://msdn.microsoft.com/en-us/library/w8h3skw9%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

"Local Security Authority (LSA)" means the user assigned to app pool, see below for more details as this turned out to be the problem.

The issue lied in the fact that we are using a dedicated user account for running the application pool, and simply creating the user and then assigning it to the app pool did not seem to trigger the creation of the registry section where the machine key is then stored. You can verify this yourself by checking registry

HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/ProfileList (for getting the SID of the user you just created; if the user is not there, then this is already a bad sign)
HKU/[UserSIDFromBefore]/Software/Microsoft/ASP.NET/... (a machine key should be stored there)

The solution was to logon as that user once on the computer (normal Windows logon screen) so that the relevant registry sections are created. There might be quicker or more subtle ways to establish the registry sections though.

It seems that enbling the `LoadUserProfile` setting on application pool level fixes the issue as well — user1859022, Feb 21 '19 at 13:43

score 1 · Answer 2 · answered Mar 02 '20 at 16:24

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introduced application pool identity, a new isolation mechanism that helps provide increased security for servers that run ASP.NET applications. However, sites that are running under the application pool identity do not have access to the HKCU registry. This is where the ASP.NET runtime stores its auto-generated keys. The result is that ASP.NET cannot persist the auto-generated key when the application pool is reset. Therefore, every time w3wp.exe is reset, a new temporary key is generated. Note This is not an issue in IIS 7.5 (Windows 7, Windows Server 2008 R2) and later versions. On these versions of IIS, ASP.NET can persist its auto-generated keys in a different location that survives application pool resets.

https://support.microsoft.com/en-us/help/2915218/resolving-view-state-message-authentication-code-mac-errors

score -2 · Accepted Answer · answered Jul 10 '09 at 14:16

-2

Forms Authentication cookies have nothing to do with Session state.

answered Jul 10 '09 at 14:16

John Saunders

160,644
26
247
397

1) Recycling your app pool does recycle your session (if you're using InProc session management), and this apparently *does* sometimes manipulate the ASPXAUTH cookie (as seen when it is removed after the BeginRequest event). 2) I'll make my question more clear by indicating "browser session." From MS documentation: createPersistentCookie Type: System.Boolean true to create a durable cookie (one that is saved across browser sessions); otherwise, false. – kamens Jul 10 '09 at 14:21
Nonsense. Cookies reside on clients. Nothing you can do to the server will remove the cookies stored on the clients. – John Saunders Jul 10 '09 at 14:33
You'd think so, right? The cookie is not being removed from the server until Application_BeginRequest is finished. I know how ridiculous this sounds, which is why I'm posting this question. I have a debugger up, and when I step from Application_BeginRequest to Application_AuthenticateRequest, the value of HttpContext.Current.Request.Cookies[".ASPXAUTH"] changes from {System.Web.HttpCookie} to null. – kamens Jul 10 '09 at 14:35
...the client obviously still sends the cookie. It's always in the browser and in the request. But it's hidden from the majority of the server-side processing of the request due to this removal. – kamens Jul 10 '09 at 14:36
Ok, you're confused between HttpContext.Current.Request.Cookies[".ASPXAUTH"], and what's on the client. It doesn't matter about this collection on the server. The client is going to send you that cookie on the next request. – John Saunders Jul 10 '09 at 14:37
No, I'm really not. The question is simply this: why does HttpContext.Current.Request.Cookies[".ASPXAUTH"] changes from {System.Web.HttpCookie} to null when I step, in a single request, from Application_BeginRequest to Application_AuthenticateRequest? – kamens Jul 10 '09 at 14:38
1

Ok, I see now that you've cleared it up. Are you sure the cookies are available so early in the pipeline?Maybe check before Authenticate event to see if cookies are present at that time. – John Saunders Jul 10 '09 at 14:54
I just added the "More debugging information" to the question above which somewhat answers this question. The cookie is still visible in Request.Cookies during FormsAuthenticate_OnAuthenticate...but if the App Pool has been recycled since the cookie was handed out, it is removed from .Cookies after this event is finished. – kamens Jul 10 '09 at 14:56
1

You also got an exception after the recycle, so it's not unexpected for it to be removed. More importantly, your exception is no doubt due to the cookie being signed with a per-AppDomain value. If that changes (as it will on a recycle), then it will be impossible for the new AppDomain to decipher the old AppDomain's encrypted cookie. – John Saunders Jul 10 '09 at 14:59
Yeah, exactly! I agree. So my only question is: why doesn't this happen for one of my IIS configurations? I want it to happen everywhere, because it makes total sense to me. It seems as though in the 2K3 IIS, it's either not using a per-AppDomain value when signing, or is somehow restoring it after App Pool recycle...not sure. – kamens Jul 10 '09 at 15:09
1

I don't know. Maybe this depends on the timing. Check the machine.config for the setting of machineKey. – John Saunders Jul 10 '09 at 15:24
Unfortunately, even w/ a setting of machineKey.validationKey="AutoGenerate,IsolateApps" and machineKey.decryptionKey="AutoGenerate,IsolateApps", this behavior continues. – kamens Jul 10 '09 at 15:49
Sorry, my question was are these settings the same across all the servers. – John Saunders Jul 10 '09 at 15:53
As far as I can tell, yes. Identical web.configs. Is there any way to tell what machineKey value is _actually_ being used, in case it's being overridden somewhere that I don't know about? It sure is behaving like AutoGenerate isn't on or isn't working. – kamens Jul 10 '09 at 16:08
1

Downvote because even though the answer is technically correct it doesn't address the question. – erikkallen Nov 12 '14 at 15:16
@erikkallen: good point. I don't know why I ever thought the OP was asking about session state. – John Saunders Nov 12 '14 at 20:52

3 Answers3

Linked