The web track sessions at DevDays highlights how important it is to access SQL Server using a trusted connection. However, the OpenHack sample application “cheats” because the web site and the database run on the same machine and you can simply configure the ASPNET account in the database.
In the real world, you don't always have web server and database on the same server. Now you no longer can just grant the ASPNET account from the web server access to the database. You need to configure your web site to run under a domain account and grant the domain account access to the database.
One way to declaratively configure under what account a web application accesses a database with is to configure the application to impersonate a domain account using the <identity> tag in the web.config file.
One advantage here is that you can apply this setting to individual ASP. NET web applications. You don't need to change the account under which the ASP. NET worker process (or the IIS app pool process ) is running.
What's even better, is that you don't have to lose any sleep because worrying about somebody getting to the account credentials because they are in clear text in the web.config file. What if somebody gets access to that file?
Well, don't worry! You can direct ASP. NET to read the credentials from an encrypted registry Key in the web.config file. The format for the identity tag is then
To get the use name and password into the registry, Microsoft supplies the Aspnet_setreg.exe tool.
This feature is also available to configure the identity of the worker process and the connection string for the session state database
Now you can securely store the identity to impersonate in the registry. If you want to kick up security another notch, then you can ACL the registry keys that hold the username and password - just as you have seen it in the open hack demo.
You can find more information and a link to download the aspnet_setreg tool from Microsoft.