Here is the scenario that we are experiencing and why we are trying to solve this:
We are a consulting company that support a particular third-party software application for a number of clients. The application is written in ASP.NET and runs on IIS and SQL Server. In this example, organization 'ABC' hosts the application on servers in their domain. This application is heavily extensible and customizable, so each of our clients would often have a repository of the customizations and they might have one or more vendors that support these customizations.
If the organization asks us or another vendor to modify an existing customization, it usually requires the setup of a local instance of the application on our machines to make development more efficient (especially debugging). We generally try to avoid hosting a local copy of their database though, and instead we connect to the organization's VPN from our local machines so that our local IIS instance can connect to their development SQL server on their network and then we setup a set of SQL credentials for the connection strings instead of using the typical integrated security.
The problem is that some organizations are not comfortable with SQL credentials being used for authentication, even on development SQL servers. I realize that there is a strong case for allowing SQL creds on the development SQL server if this scenario needs to be supported, but what I am trying to find out is if their is any other option at all. The organization's own engineers are able to configure their local IIS application pool identities to use domain credentials for accessing the SQL servers using integrated security. However, external vendors (liked us) are not joined to their domain and the domains are not trusted, so I cannot use organization ABC's provided domain credentials as my application pool identity.
Is anyone aware of a possible way to have an IIS application running on a machine from domain 'XYZ' use Integrated Security to authenticate to a SQL server running in domain 'ABC' without trusting domains or setting up Kerberos delegation?
I have considered trying to use the various built-in accounts as the application pool identity and trying to grant them access on the SQL server, but we do not want to be granting access on the SQL server for every possible combination of DOMAIN\MachineName$ that might be connecting to it from all the different vendors. Maybe if a naming convention was followed on the application pool name and we used the ApplicationPoolIdentity then we could possibly grant access on the SQL server to only one 'virtual' account? (I have not tried this and plan on doing so when time allows).