Mike,

The most common approach to this common problem is to specify SQL
credentials in the connection string. The downside here is that you need to
protect the connection string at storage, which is a challenge, but unless
you have certain specific conditions, you do not have many alternatives. If
you want to propagate user's credentials to SQL server, you have to enable
delegation at the AD domain level, which is not a good idea from security
perspective. And what is worse, your app will not be able to use connection
pooling, so the scalability goes down he drain. If you want to connect to
SQL Server using credentials of the IIS worker process, you either need to
run the IIS process as a domain user or set them identically on both the SQL
serve and Web server using a local account (with the same password). I don't
think that either of these options is good, because if you do this (for one,
any application running under your Web site will be able to connect to SQL
server with privileged rights). The bottom line here is that you will
introduce more problems than you solve. Just go with the SQL credentials in
the connection string. From my experience, this is what most enterprise apps
do.

Alek