Codebureau - Matt Simner

Access control and troubleshooting 401 errors must be one of the most annoying and recurring issues with configuring IIS.  One of the problems is that it's often quite a long time between issues, and you simply forget how you solved something last time.  This time I decided to write it all down as I set things up.

Target Scenario
My target scenario is a local intranet, where you want to use a 'service account' to access SQL Server, directly from your 'trusted' web application, removing the need for impersonation. 

The benefits of this are of course that you can take advantage of connection pooling, but also removing the need to configure passwords in web.config for SQL users (or specific, impersonated domain users).  This also removed the overhead of configuring specific domain users and their SQL Server permissions.  It may also be that you just want to simplify your security model to work only on Windows authentication across the stack.  

SQL Server

1. Create a new role in the database you're accessing, for the purposes of your application
2. Add your service domain user account to the role in SQL Server
3. Assign permissions to objects, stored procedures etc to the role (not directly to the user)
   

IIS/Web Site

1. Set up your web site/application as you would normally - one way to do things....
1. Create your web application root folder on the web server
2. Copy your files (or use your deployment tools/scripts to do this)
3. Create a new application pool to house your new web application (probably model this from the default web site).  This is important as this is where the credentials will be set
4. Create the new IIS web application against the root folder (if not already done as part of step 2)
5. Associate the new IIS application with the new application pool
6. Set the ASP.NET version of your IIS application appropriate (may need to restart IIS here)
2. Ensure 'Integrated Security' is set ON in the Directory Security tab, and 'Anonymous' access is switched OFF
3. Set the application pool's 'identity' to the domain user you want to run the application (and connect to SQL Server) as
4. Open a command window and Go to the windows\Microsoft.NET\Framework\vXXXXX folder
1. run aspnet_regiis -ga <domain>\<user> to grant necessary access to the metabase etc for the service account (as per http://msdn.microsoft.com/en-us/library/ff647396.aspx#paght000008_step3 )
2. In the command window go to the inetpub\adminscripts folder, and set NTAuthenticationHeaders metabase property as per instructions at http://support.microsoft.com/kb/326985.  you can also use MetaEdit from the IIS Resource Kit to change this.  If you're fully configured to use Kerberos then you can potentially skip this step, as it's all about making IIS use NTLM authentication.
   
5. Navigate to 'Web Service Extensions' in IIS Manager, and ensure that the ASP.NET version you're targeting is 'allowed'.  e.g. ASP.NET 4.0 is 'prohibited' by default.
   

Summary
So here we've circumvented the need to use impersonation by running the ASP.NET application as a specific domain user that is configured as a SQL Server Login, and granted the right access by means of a SQL Server role.  The main work is the plumbing to get IIS to work happily with that user in standard NTLM authentication (you may be able to use Kerberos depending on your network configuration).

Other background on creating service accounts can be found at http://msdn.microsoft.com/en-us/library/ms998297.aspx