以下是我们遇到的情况以及我们试图解决这个问题的原因：
我们是一家咨询公司，为许多客户提供特定的第三方软件应用程序支持。该应用程序用 ASP.NET 编写，并在 IIS 和 SQL Server 上运行。在此示例中，组织“ABC”在其域中的服务器上托管该应用程序。此应用程序具有很强的可扩展性和可定制性，因此我们的每个客户通常都会有一个自定义存储库，并且他们可能有一个或多个支持这些自定义的供应商。
如果组织要求我们或其他供应商修改现有的定制，通常需要在我们的机器上设置应用程序的本地实例，以提高开发效率（尤其是调试）。不过，我们通常会尽量避免托管其数据库的本地副本，而是从本地机器连接到组织的 VPN，以便我们的本地 IIS 实例可以连接到其网络上的开发 SQL 服务器，然后我们为连接字符串设置一组 SQL 凭据，而不是使用典型的集成安全性。
问题是，一些组织不愿意使用 SQL 凭据进行身份验证，即使在开发 SQL 服务器上也是如此。我意识到，如果需要支持这种情况，那么在开发 SQL 服务器上允许使用 SQL 凭据是很有道理的，但我试图找出的是是否还有其他选择。组织自己的工程师能够配置他们的本地 IIS 应用程序池身份，以使用域凭据访问使用集成安全性的 SQL 服务器。但是，外部供应商（如我们）未加入他们的域，并且这些域不受信任，因此我无法使用组织 ABC 提供的域凭据作为我的应用程序池身份。
是否有人知道一种可能的方法，可以让在域“XYZ”的计算机上运行的 IIS 应用程序使用集成安全性对在域“ABC”中运行的 SQL 服务器进行身份验证，而无需信任域或设置 Kerberos 委派？
我曾考虑过尝试使用各种内置帐户作为应用程序池标识，并尝试授予它们对 SQL Server 的访问权限，但我们不想为所有可能连接到它的 DOMAIN\MachineName$ 组合授予对 SQL Server 的访问权限，因为所有不同的供应商都可能连接到它。也许如果在应用程序池名称上遵循命名约定，并且我们使用 ApplicationPoolIdentity，那么我们可能只向一个“虚拟”帐户授予对 SQL Server 的访问权限？（我还没有尝试过，计划在时间允许时这样做）。
答案1
如果您不是其域的成员或至少没有信任，这是不可能的。
您的服务器不了解其他域是什么，并且没有任何凭据可以让您验证（或发现）其域。 Windows 通常不会让您以不信任的机构（域）的用户身份运行进程，因此您无法设置应用程序池标识，因为工作进程将尝试以该用户身份运行。