Kev's Big Log - ASP.NET 2.0 aspnet

ASP.NET 2.0 aspnet_regiis -ga Switch

There's a handy new switch in the ASP.NET 2.0 IIS Registration Tool (located in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 in a default installation) that makes life easier when creating custom service accounts for ASP.NET 2.0:

aspnet_regiis -ga <useraccount>

In a nutshell this takes the pain out of creating a service account and configuring all the required NTFS permissions, IIS_WPG group membership, security policy user rights assignments and IIS metabase access rights (see more here http://msdn2.microsoft.com/en-us/library/ms998297....).

Importantly, if your server is configured to use an auto-generated machine.config <machineKey/> this switch also ensures that the following registry key is created when ASP.NET 2.0 starts up: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys. Below this an additional key is created for the custom service account SID and is used to store the auto-generated machine key. e.g.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\S-1-5-21-3520846933-1734744541-1252751799-1013

Under this key there are three values -

AutoGenKey - this is the auto-generated key
AutoGenKeyCreationTime - when the key was generated
AutoGenKeyFormat - 1 = Encrypted, 2 = ClearText

If you don't use aspnet_regiis -ga to configure the custom service account and you use an auto-generated key you can run into problems when using persistent encrypted Forms Authentication cookies. The reason for this is that configuring the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys registry key can be overlooked or be incorrectly configured (e.g wrong permissions) if performed manually. If this key is not present or the custom service account doesn't have the correct permissions on the key, ASP.NET 2.0 will be unable to persist the machine key (the Local Security Authority is no longer used by ASP.NET 2.0 to store auto-generated keys). In this situation, if the ASP.NET 2.0 application pool is recycled or IIS is restarted then a new machine key will be generated because ASP.NET is unable to retrieve they previously generated key from the registry. This will invalidate existing persistent encrypted forms authentication cookies and you'll see entries in the Application Event log such as this:

Event Type: Information
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1315
Date: 26/10/2006
Time: 02:04:34
User: N/A
Computer: FNORD
Description:
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.
Event time: 26/10/2006 02:04:34
Event time (UTC): 26/10/2006 01:04:34
Event ID: fac38d2aaeeb42a19e188ee838c1ca22
Event sequence: 2
Event occurrence: 1
Event detail code: 50201
Application information:
Application domain: /LM/W3SVC/1120939903/Root/tickets/77695-2-128062982739821344
Trust level: Medium
Application Virtual Path: /tickets/77695
Application Path: E:\AppsDev.Net\Handy Scripts\HandyASPScripts\tickets\77695\
Machine name: FNORD
Process information:
Process ID: 1716
Process name: w3wp.exe
Account name: FNORD\aspnet2_wp7
Request information:
Request URL: http://apptest.net/tickets/77695/Default.aspx
Request path: /tickets/77695/Default.aspx
User host address: 172.16.3.114
User:
Is authenticated: False
Authentication Type:
Thread account name: FNORD\I_icsoff
Name to authenticate:
Custom event details:

If you're using a manually generated static machineKey, which is a requirement when operating in a load balanced or clustered configuration then you'll probably not encounter this problem e.g. -

<machineKey validationKey="97F97E2D6939D2C ... 1CEA30726A56E3DB5E"

decryptionKey="3AE64F1DC0167BB814D09162BDEF5E38B027E0E9E9AD7EA7"

validation="SHA1"/>

Load balanced/clustered servers require that you use the same machineKey across all the servers, otherwise subsequent HTTP requests may hit different machines in the set, and unless the machineKey's are the same, the encrypted authentication cookie cannot be decrypted and you'll almost certainly see events like above in the Application Event log.

So in summary, take the pain away and let aspnet_regiis -ga perform the configuration heavy lifting for you.