DaveWentzel.com            All Things Data

Authentication Issues

 

Delegation, "double hop", authentication issues, etc
double hop problem/impersonation

It's a best practice not to connect your web application to sql server using a hard coded sql acc't.  Your alternative is to use trusted connections.  In ASP.Net your web application likely runs under the context of the ASPNET user on the local web machine.  This is a local user acct.  If the sql server shares the box with IIS this isn't a problem. 
 
But what do you do when sql is on a separate box and doesn't have the ASPNET user acct?  You can of course create the user and sync passwords (or use a domain user acct).  This is a bad idea since a hacker that breaks that acct could compromise your entire domain.  You can use impersonation and change the context your pages run under.  You can also run IIS in native application mode.  Another method is to encrypt the sql acct pwd in the IIS server's registry and point to that reference (KB 329290). 
 
Native mode is probably the best option, but only available in 2003.  This allows you to create application pools that run under defined credentials and offer other benefits such as performance...you can recycle individual app pools without affecting other applications. 
 
Problems with this...sql connection pooling.  If each connection is opened with a different user acct then each will need a separate connection...no pooling.  There is a slight performance hit since the authentication token is verified outside of sql server, escalating at least to the NT authentication system...if not to the actual domain controller. 
 
 
Login failed for user 'NT AUTHORITY\SYSTEM'.
 
You can see these errors when setting up linked servers or a web server that uses NT authentication.  The error is due to the double hop issue with Kerberos.  Some good information can be found at these links. 
 

Add new comment