Deploying a web application and a database to a single server is pretty straightforward. In fact, it's quite common. However, for a variety of reasons, it may be necessary to separate the database from the web application into two (or more) physically separate machines. Many a developer may be caught unawares by potential database authentication issues that may arise in this scenario.
If your web application accesses the database directly, with its own set of credentials, your task may not be too complicated. You may simply need to make sure that Sql Authentication is enabled on the SQL Server. If Windows Integrated Security is required, there are ways you can accomplish this as well, such as by programmatically impersonating a user, or perhaps by using a COM+ package with a specific identity.
If, on the other hand, your application needs to flow the end user's credentials (e.g. the browsing user's credentials) to the database there are some other things you'll need to consider. This type of application is common place in a corporate intranet where a user logs on to his machine and can then navigate to a company portal without requiring an additional logon. The authentication simply happens behind the scenes between the browser and the site.
Due to restrictions imposed by how NTLM works, however, if you must use integrated security and your database server is physically separate from your web application you will be unable to access the database through the website (though you would if you connected directly). This is because NTLM causes the server to authenticate the client. The client security token is authenticated by the web server. When the time comes to connect to the SQL Server as the user, the database server will attempt to authenticate the client (in this particular connection the web server is the client). The web server will not have the client token so authentication fails. Essentially, you're given one network/machine “hop“ with your credentials.
This is where Kerberos comes into play. Kerberos will allow your credentials to flow further, giving the database server the ability to ascertain your security token and grant you access.
If you're developing an ASP.NET application and need this functionality, there are a few things you should have in place to allow for the client credentials to flow across multiple machine boundaries like this:
- Make sure impersonation is set in the web.config via <identity impersonate=“true“ />
- Make sure that the website is set for Windows Authentication / Integrated Security (not anonymous). If you set for Basic Authentication, the client will be prompted to login upon connecting and the web server will contain the security token and will then, upon attempting to query the database, make its one allotted network “hop“...but that defeats the purpose of the single sign-on we achieve with Windows Authentication.
- Make sure that the machine is trusted for delegation. This is accomplished in the Active Directory Users and Computers console.
- Make sure that your connection to the remote database is using Named Pipes.
While troubleshooting this scenario you may encounter an error such as “Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'”. In such an event it is possible that Kerberos is enabled but you're accessing the remote SQL Server via TCP/IP. Make sure that your connection string specifes to use Named Pipes.