In many cases it is desirable to authenticate a ASP.NET web app using Windows Authentication. Allows you to avoid storing the username/password in clear text in the web.config file, and allows for the central management of accounts without the need to maintain SQL Server accounts.
Microsoft has some helpful instructions on how to accomplish all this for the .NET 2.0 framework. This article describes how to accomplish the configuration in .NET 2.0. The article also links to another article that describes how to create a service account for use with this type of authentication.
NOTE: All of this assumes that you want to use a single account for your web app and give that account access to the database. The application itself is responsible for authenticating users and making sure they have rights to perform all operations within your application. This is referred to as a trusted subsystem model. As such, the discussion below assumes that you are not using impersonation the users that are accessing your web app.
The same techniques can be applied to .NET 1.1 (and probably 1.0) ASP.NET apps. There are two ways to setup the Windows Authentication: using the Network Service account on your webserver (the easy way) and using a domain authenticated account specific for your application (the hard way).
Network Service Authentication
Starting with the Network Service account approach, you only need to do two things:
- Give the account access to your database via SQL Server Management studio (assuming SQL Server 2005; with 2000 you would use Enterprise Manager)
- Configure your connection string in your web.config file (or wherever you are storing it)
To configure SQL Server, create a new login with the login name:
So my web server, Fozzie, on the Example domain would be Example\Fozzie$. Be sure to use Windows Authentication when you create the login, and be sure to map the login to the appropriate users on your desired database.
To configure your database connection string, use one of the equivalent options Trusted_Connection=Yes or Integrated_Security=SSPI. So your database connection strings would be of the form (stolen from Microsoft article):
Initial Catalog=MyDb;Data Source=MyServer;Integrated Security=SSPI;
The disadvantage of using the Network Service account to authenticate your application with SQL Server is that all web applications running on the same server will use the same account to authenticate, and thus will have access to each other’s databases. If this is not acceptable, the other option is to use a domain account for your web app.
Using a domain account to run your web application will give you more granular control of the application’s access to resources and will allow you to isolate different applications running on the same server. Configuring a web application to run as a domain account involves the following steps:
- Create a domain account for use with the application
- Give account access to database in SQL server
- Give account needed rights to run ASP.NET application
- Revoke right for account to log on locally to computers
- Create app pool in IIS that uses the domain account as its process identity
- Configure web application to use custom app pool
- (optional)Create service principal names (SPNs) for the domain account
This blog post has some additional information about using a domain account to run an IIS app pool.