Asp.net 应用程序池标识或模拟

（有人问了一个类似的问题，但问题和公认的答案都没有提供我想要的细节）

为了在专用域帐户下运行asmx web服务，与模拟相比，使用具有域帐户身份的应用程序池的使用场景和/或优缺点是什么

我们有3个小型的内部web服务，它们在相对较低的负载下运行，我们希望将它们切换到在自己的域帐户下运行（为了与SQL Server等集成安全性）。我似乎可以选择为每个应用程序创建专用的应用程序池，或者为所有应用程序创建一个应用程序池，并在每个应用程序中使用模拟

---

我知道应用程序池提供工作进程隔离，并且在使用模拟时会考虑性能，但是除了这些因素之外，还有哪些因素会决定正确的选项？

通常，您会为工作进程选择不同的标识（或进行ASP.NET模拟）因为需要访问需要特定权限的本地/网络资源。明显的缺点是，您的应用程序代码可能在超出其需要的权限下运行，从而增加了抵御恶意攻击的漏洞

---

ASP.NET模拟的开销会更大，因为每个请求都需要切换用户上下文。我建议使用单独的应用程序池方法-应用程序池方法的唯一缺点是，它们中的每一个都有进程，因此每个进程都会有开销（从操作系统的角度来看）。如果您的应用程序较小，并且没有很强的内存需求，那么这不应该是一个问题，

当您需要使用基于Windows安全性的其他Windows服务获得共同的最终用户体验时，模拟非常有用

例如，Microsoft SharePoint服务器使用模拟，因为您可以使用web浏览器和标准Windows共享UI访问SharePoint文档库（根据协议连接/断开网络共享）。为了确保两者之间的安全性是一致的，在这种情况下，您需要模拟

---

除了这种情况之外，模拟在大多数情况下是没有用处的（但在可伸缩性方面会花费很多）

我建议您查看下一页的安全详细信息

---

完成此操作后，您将“准确地”看到模拟如何更改身份。

应用程序池的优点：

你不必是一个.Net程序员就能理解正在发生的事情

安全方面离开了程序员的领域，属于基础设施的职责范围

在设置应用程序池时，通过IIS轻松更改，并使用适当的安全性检查用户名是否正确。也就是说，它不会让你输入错误的用户名

模拟专业人士：

如果配置文件存储在源代码管理历史记录中，则可以记录特权并通过对配置的更改进行追溯

模拟缺点：

要更改用户，您需要熟悉.Net配置，而不仅仅是设置网站

我想不出还有什么别的办法

---

我的直觉告诉我，每个网站都有不同的应用程序池，但这是你的一方。

如果你想让你的web服务通过Windows身份验证连接到SQL，你几乎肯定会想用专用的应用程序池选项设置每个应用程序。这需要最少的设置和管理

如果您选择模拟路径，则需要考虑“两跳”问题。当用户调用使用模拟的web服务时，该web服务可以作为该用户访问本地资源。但是，如果web服务尝试连接到非本地资源（例如，运行在单独服务器上的数据库），则结果将是身份验证错误。原因是NTLM阻止您的凭据进行多个“跃点”。要解决这个问题，您需要使用Kerberos委派。委派设置并不困难，但它确实需要域管理员权限，这在某些公司环境中会使事情变得困难

---

此外，使用模拟意味着您需要为可能访问web服务的每个用户管理数据库权限。数据库角色和广告组的组合将大大简化这一过程，但这是一个额外的管理步骤，您可能不希望执行。这也是一个可能的安全风险，因为某些用户可能最终拥有比您的web服务预期更高的权限。

使用应用程序池标识可能会比模拟更让人吃惊。链接不再有效，我认为这是您想要链接的页面（希望此链接能够持续）