ASP.NET allows you to change the underlying Windows account that is used for the identity of the aspnet_wp.exe worker process. It looks like this:
<identity impersonate=”false” userName=”SpecialASPNETaccount” password=”Pa$$w0rd”/>
Pretty obviously this is not a desired option. Microsoft has the aspnet_setreg.exe tool that allows you to securely store these credentials in the registry. It will encrypt the values of username and password and store these in the registry key of your choice. With ACLs this key is protected and given only rights for the original worker account (usually ASPNET, if you haven’t changed that in the machine.config). Your web.config will need to be adjusted accordingly (see below).
The aspnet_setreg.exe tool behaves somewhat strangely. I found out during a presentation. David Carroll contacted me to ask if I got it working after that as he was having problems as well to get it configured correctly. I tried again and got it working the first go. So much for trying to reproduce the behavior.
What I did find is that the documentation of the tool itself (aspnet_setreg.exe -?) is misleading. You need to set the correct permission on the ASPNET_SETREG subkey that the tool creates. Let’s say you run the tool like so:
aspnet_setreg.exe -k:SoftwareMyCompanyMyApplicationIdentity -u:SpecialASPNETaccount -p:Pa$$w0rd
you will get a set of registry keys that look like so:
The web.config should now contain the following to make the impersonation work:
<identity impersonate=”false” userName=”registry:HKLMSoftwareMyCompanyMyApplicationASPNET_SETREG,userName” password=”registry:HKLMSoftwareMyCompanyMyApplicationASPNET_SETREG,password”/>
The documentation states that you need to set proper permissions (Read to be exact) to “the registry key” for the process identity. This is the unimpersonated identity (usually ASPNET). It doesn’t say that this key should be the ASPNET_SETREG subkey. That’s where you have to set the permissions. David also reported after experiments of his own that rerunning the tool with the same parameters will effectively delete the existing key and recreate it. This has the unwelcome side-effect that your previously set permissions have been reset.
You can also use aspnet_setreg.exe to securely store the sql or state connectionstring for session state. Examples of these would be:
aspnet_setreg.exe -k:SoftwareMyCompanyMyApplicationSessionState -c:”DATA SOURCE=(local);INTEGRATED SECURITY=SSPI”
aspnet_setreg.exe -k:SoftwareMyCompanyMyApplicationSessionState -d:tcpip:127.0.0.1:42424
As before set the read rights for the ASPNET_SETREG subkey. The web.config should contain the following:
<sessionState mode=”InProc” stateConnectionString=”registry:HKLMSoftwareMyCompanyMyApplication SessionStateASPNET_SETREG,stateConnectionString” sqlConnectionString=”registry:HKLMSoftwareMyCompanyMyApplication SessionStateASPNET_SETREG,sqlConnectionString” cookieless=”false” timeout=”20″/>
which allows you to change the session state to StateServer or SQLServer, but using encrypted connection strings.
Another feature is that you can check the permissions for the keys that have been created. Just replace the -c, -d or -u/-p switches to -g.
Questions and comments are welcome, as always.