Windows
1. Create a new user account. Do not grant any additional permission beyond putting it into the ‘Users’ group (which is done by default).
NOTE: If SQL Server and IIS are running on different servers, the account you create must be a domain account. If SQL Server and IIS are on the same server, it can be a local account (unless ASP.NET will need to access any network resources).
2. Grant the account that you create read/write access to the folder: C:\Documents and Settings\<machine name>\ASPNET\Local Settings\Temp. This is needed for ASP.NET to be able to do its work.
IIS
3. Change the impersonated user for anonymous access to your Web Application in IIS to the newly created user. The default user is IUSR_<machine name>. You change this by right-clicking on your Web Application in IIS and going to the properties. Under the Directory Security tab, edit the account used for anonymous access.
ASP.NET
4. In your Web Application’s Web.config file, add the following line to the system.web section:
<identity impersonate="true"/>
This will cause ASP.NET to run under the credentials of the anonymous IIS user (which in step 3 was set to the user you created).
SQL Server
5. In SQL Server, grant access to the user you’ve created only for the database(s) used in your Web Application. Give as little access as is necessary. I recommend that all of your SQL Server functionality take place in stored procedures, and that access be granted only to execute those stored procedures. Do not enable any direct table access at all if you can help it.
6. With the above done, remove any credentials passed in the connection strings to SQL Server and replace them with “Trusted_Connection=Yes”.
7. Finally, since ASP.NET is impersonating the user you have created, Windows authentication is all that is necessary for SQL Server, so if SQL Server is running in mixed mode, change it to Windows only mode. This is done in Enterprise Manger. Right-click on the server and go to Properties. The setting is found under the Security tab.
NOTE: Follow this step only if you are sure that all applications accessing SQL Server have made the necessary changes to use Windows authentication! Any application not switched to using trusted connections will be denied access once the change is made.
8. If you must operate SQL Server in a mixed mode environment, make sure the sa password is not blank and is set to an alphanumeric value of at least 8 characters. When in Windows authentication mode, the sa user cannot be used, so this is not an issue.
MS Access
9. If you are connecting to an Access database from your ASP.NET application, you will need to grant the new user Read and/or Write privileges to the MDB file. Only grant Write privileges if the web application will be inserting into the database.
Network Resources
10. If accessing any network resources from your web application, do so only through objects installed in Component Services running under accounts restricted to accessing only the necessary resources. As always, if write access is not needed, don’t grant it. Never grant the ASP.NET impersonated account access to network resources directly. If your COM objects are created in .NET, remember to register them using regsvcs.exe—lazy registration will fail if ASP.NET tries to create the COM object.
A while back I wrote a blog detailing how to securely access network resources from an ASP.NET web application.