Trusted Connection

[Chris Davoli]

We are changing from using SQL accounts in our connection string to use NT
domain accounts. I have found some coe which I am using successfully on my
local machine, because the installed account ie; MachineName\ASPNET is what I
use in my VS2005 environment and this works great connecting locally to my
local SQL Server DB, since it is one of the accounts that I have locally as a
user in SQL Server.

The problem is when I try to connect to another remote SQL server (a test
server), it tries to use this same account (MachineName\ASPNET), and it can't
because it is not on the remote SQL Server box as an assigned user in SQL
Server for that Database. I don't want to use my machine name account ie;
MachineName\ASPNET, but I would like to use a domain account ie;
DomainAccount\ASPNET and I know I need to put this account on my local
machine and also add it to SQL Server and assign it to the database that I
want to connect to. My question is, where do I specify the name of this
domain account? Does it go in the web config file, or do I specify it in the
connection string, or is it specified as an impersonation in the web config
file? I'm assuming it would be in the web config using impersonation. I've
never used this. How do I do this? Here is my connection string:

<!--<add key="cnx_db" value="Server=XXXXXXXXXXX;Integrated
Security=True;Database=XXXPortal;Persist Security Info=True" />-->

 

[Joe Kaplan \(MVP - ADSI\)]

I'm assuming you are using Win2K or XP since the ASPNET account is being
used. There are two ways you might approach this. You can either change
the process account for the worker process (done in the processModel tag in
the machine.config), or you can impersonate a specific identity in the
web.config file for the app in question.

In either case, you'll need an appropriate domain account to use as the
service account, so unless you use your user account for this, you'll need
to get a service account in the domain from your domain admins.

Impersonation in web.config (via the <identity> tag) has the advantage of
only applying to a specific app instead of being global. Note that it won't
work on Win2K by default though, as on Win2K, the ASPNET account does not by
default have rights to impersonate a fixed account with credentials
specified.

It is also possible to impersonate programmatically in your code before
doing a SQL operation, but you might not want that code in the production
version and it might not be worth it to factor it out into some sort of a
pluggable model.

There is also the possibility of running your ASP.NET worker process as
SYSTEM which will then appear to the remote machine as the machine account
(which is probably a domain account). The downside there is that you are
significantly increasing the attack surface of your machine by doing that,
so it is not a good idea. Another option is to develop on 2K3 machines so
you can use IIS 6 and can configure the app pools directly or just use the
NETWORK SERVICE account.

HTH,

Joe K.