title: How to get ASPNET to be recognized as a Trusted Connection by SQL Server 2005
body: <p>Here's the situaiton.  I'm working on developing a new website to access an old database.  This is a DoD installation so there's lots of security around.</p>
  
  <p>The current application is written in classic ASP, VBScript and some javascript.  The new systems is ASP.NET.</p>
  
  <p>Accessing the database in the old system meant hitting the server with your own credentials (domainname\username).  Now I'm trying to test some of the early development I've done.  When I used Cassini (under VS2008), I had no trouble getting to the database because ourdomain\myusername registered with the SQL Server instance as a trusted connection.  Due to security aspects that I have to write, Cassini can't serve as a test server anymore - I have to use IIS (we have security card readers here).  Cassini can't handle them.</p>
  
  <p>So when I went through all the problems of getting the appropriate accounts added to Administrators on my local pc so that I could debug in VS2008 while using IIS, I tried to connect to the database and I was rejected because MYPC\ASPNET was not a trusted connection.</p>
  
  <p>Altering the existing database is out of the question.  Hard coding usernames and passwords for access to the database is out of the question.</p>
  
  <p>I asked the DBA if he could add MYPC\ASPNET to of the domain groups so that SQL Server could see it as a trusted connection (since MYDOMAIN\MYNAME was in a group that was seen as a trusted connection).  He tells me that is not technically possible.</p>
  
  <p>In the end there are going to be three or four machines (mine, another developer, the eventual live web server and a future test web server) who's ASPNET accounts are going to be hitting our two SQL servers (live and test).</p>
  
  <p>What do I have to do to make the existing SQL server see me as Friend and not Foe?  I looked at impersonation but I get the impression it's not compatible with our system - the business rules make a call to a common routine to create a SqlConnection object and open it (maybe even a SqlTransaction object to go with it) and this object is used for the rest of the business rules and data-access layer until it's done.  It didn't look like impersonation would persist once the SqlConnection was opened (and passed, ByRef back to the calling routine)</p>
  
  <p>Thanks in advance for any advice.</p>