我有一个运行在服务器A上的IIS应用程序。它需要能够写入UNC共享上的文件夹，当前在服务器B上。我想保留服务器B上的共享，但是这个环境没有Windows Active Directory域 – 直到这一点，我们已经通过运行任何给定服务（例如DB）下的帐户，其用户名和密码将被复制到服务需要访问的任何其他服务器上解决此问题。 直到这一点，我们不知道IIS应用程序需要“域样式”访问任何其他资源，它尚不具备authentication的替代方法。
IIS应用程序具有设置Identity: ApplicationPoolIdentity ，根据我的理解，它将在SID IIS AppPool\AppPoolName下运行
那么经过一些最初的研究和发现之后，我想出了以下几种可能性，从最小到最优雅的顺序排列。 我的意见是斜体。
将共享移到服务器A上
不是我想要做的事情 – 需要大量现有服务的重新configuration，与其他基础设施不一致。
将有问题的文件夹移动到服务器B上的一个新的共享上，具有匿名写权限。
这至less会把我所有的股份保留在同一台服务器上，但是默默无闻的安全性并不是我的风格。
将IIS应用程序重新configuration为在明确的用户名和密码下运行，以在服务器B上复制以授予对文件共享的访问权限。
至less我认为这样做会达到我想要的效果，但是改变身份似乎是有风险的，并且可能会对应用程序产生不可预见的后果。
为服务器A上的应用程序池标识提供存储的凭据，以获取用户名和密码，以便访问服务器B上的共享。
不知道这实际上是否工作，或者如果你甚至可以把存储的凭据给不是完整的用户帐户的SID。 只是一个想法，但我喜欢它，因为它不影响IIS应用程序的现有configuration。
使用共享上的ACL将访问权限授予服务器A的“计算机帐户”
这看起来像是圣杯，因为它是推荐的方法 （“应用程序池标识也使用机器帐户来访问networking资源”），但是这些机器当然不会绑定到Windows域，这似乎是使用机器帐户。
理想情况下，我想find一个黑客或kludge，将完成项目＃5或一些其他方式授予访问权限完全通过重新configuration服务器B，再次没有AD域。 在任何情况下，我也想知道在这种情况下更有经验的Windows Serverpipe理员会做什么（除了设置一个该死的Active Directory域）。
没有Windows域的唯一选项实际上是将应用程序池标识更改为有权访问的帐户。 如果没有什么特别的事情与现有的身份，你应该只需要创build一个基本的用户帐户（它不需要一个configuration文件），并将其分配为身份。
在运行时，它将被赋予IIS_IUSRS组，并具有与默认应用程序池标识相同的访问权限。