Thanks Paul. I found a lot of contradictory documentation, from Microsoft, about whether to use Basic vs. Windows Integrated security. I included the conflicting statements and URLs below. I also encountered two additional problems that I didn't easily find in any of the SQL/IIS documents. One, if the website uses a name other than the server name (host name), this needs to be registered as a SPN in AD. Two, I had to modify the web.config file because of this http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx Colin
“In IIS, only Basic Authentication logs users on with a security token that flows across the network to a remote SQL server. By default, other IIS security modes used in conjunction with the identity configuration element settings will not result in a token that can authenticate to a remote SQL Server.”
http://msdn.microsoft.com/en-us/library/bsz5788z.aspx
“To use a SQL server database, configure the security settings of your project to work with Integrated Security. To do this, turn off anonymous access and turn on impersonation, as indicated in the following procedure.”
http://msdn.microsoft.com/en-us/library/aa302120(VS.71).aspx
“If you enable impersonation and do not specify a domain account as the identity, you will not be able to connect to another computer on the network unless your IIS application is configured to use Basic authentication.”
http://msdn.microsoft.com/en-us/library/xh507fc5.aspx
“You should use Integrated Windows authentication instead of basic authentication because it avoids transmitting user credentials over the network. Because Kerberos v5 authentication supports mutual authentication, users can also authenticate the server to which they are connecting. Integrated Windows authentication is best suited for an intranet environment, where both the client and Web server computers are part of the same, or trusting, domains.”
http://msdn.microsoft.com/en-us/library/aa480475.aspx
“By using impersonation, ASP.NET applications can execute code or access resources with the identity of the authenticated user or a fixed Windows identity. Standard impersonate-level impersonation tokens that are usually created when you enable impersonation allow you to access local resources only. To be able to access remote network resources, you require a delegate-level token. To generate a delegate-level token when you impersonate, you need to use Kerberos authentication and your process account needs to be marked as trusted for delegation in Active Directory.”
http://msdn.microsoft.com/en-us/library/ms998358.aspx