（之前已经提出过类似的问题，但问题和接受的答案都没有提供我正在寻找的细节）
为了在专用域帐户下运行 asmx Web 服务，使用具有域帐户身份的应用程序池与模拟使用应用程序池的使用场景和/或优缺点是什么？
我们有 3 个小型内部 Web 服务，它们在相对较低的负载下运行，我们希望将它们切换为在它们自己的域帐户下运行（为了与 SQL Server 等集成安全性）。我似乎可以选择为每个应用程序创建专用应用程序池，或者为所有应用程序创建一个应用程序池并在每个应用程序中使用模拟。
我知道应用程序池提供了工作进程隔离，并且在使用模拟时需要考虑性能，但是除了这些之外还有什么可以决定正确的选项？
通常，您将为工作进程选择不同的身份（或进行 ASP.NET 模拟），因为需要访问需要特定权限的本地/网络资源。明显的缺点是您的应用程序代码可能在比它可能需要的更多权限下运行，从而增加了抵御恶意攻击的漏洞。
ASP.NET 模拟会产生更多开销，因为需要为每个请求切换用户上下文。我建议使用单独的应用程序池方法 - 应用程序池方法的唯一缺点是每个进程都有进程，因此每个进程都会有开销（从操作系统的角度来看）。如果您的应用程序较小并且没有强大的内存需求，那么这应该不是问题，
如果您希望您的 Web 服务通过 Windows 身份验证连接到 SQL，您几乎肯定会希望使用专用应用程序池选项设置每个应用程序。这需要最少的设置和管理。
如果您走模拟路线，则需要考虑“两跳”问题。当用户调用使用模拟的 Web 服务时，该 Web 服务可以以该用户的身份访问本地资源。但是，如果 Web 服务尝试连接到非本地资源（例如，运行在单独服务器上的数据库），结果将是身份验证错误。原因是 NTLM 会阻止您的凭据进行多次“跳跃”。要解决此问题，您需要使用 Kerberos 委派。委派的设置并不难，但它确实需要域管理员权限，这在某些公司环境中可能会使事情变得困难。
此外，使用模拟意味着您需要为每个可能访问您的 Web 服务的用户管理数据库权限。数据库角色和 AD 组的组合将大大简化此操作，但这是您可能不希望执行的额外管理步骤。这也是一个可能的安全风险，因为某些用户最终可能会获得超出您的 Web 服务预期的权限。
当您需要与其他基于 Windows 安全性的 Windows 服务的共同最终用户体验时，模拟非常有用。
例如，Microsoft SharePoint 服务器使用模拟，因为您可以使用 Web 浏览器和 标准 Windows 共享 UI（基于SMB协议连接/断开网络共享）访问 SharePoint 文档库。为了确保两者之间的安全性一致，在这种情况下，您需要模拟。
除了这种情况，模拟在大多数情况下是没有用的（但在可扩展性方面可能会花费很多）
应用程序池优点：
您不必成为 .Net 程序员也能理解正在发生的事情。
安全方面离开了程序员的领域，属于基础设施的职权范围
通过 IIS 轻松更改设置应用程序池时，通过适当的安全检查用户名是否正确。即它不会让您输入错误的用户名。
模仿优点：
模仿缺点：
不知道我还能想到很多其他的。
我的直觉告诉每个网站使用不同的应用程序池，但这是你的聚会。
我建议您查看以下页面以获取安全详细信息...
https://www.attosol.com/sample-aspx-page-to-show-security-details-in-asp-net/
完成此操作后，您将“准确地”看到模仿如何改变身份。