我在服务器 A 上运行了一个 IIS 应用程序。它需要能够写入 UNC 共享上的文件夹，而 UNC 共享目前位于服务器 B 上。我想保留服务器 B 上的共享，但此环境没有 Windows Active Directory 域 - 到目前为止，我们已解决了此问题，方法是使用一个帐户运行任何给定服务（例如 DB），该帐户的用户名和密码将复制到该服务需要访问的任何其他服务器上。到目前为止，我们并不知道 IIS 应用程序需要“域式”访问它尚未拥有其他身份验证方法的任何其他资源。
IIS 应用程序具有设置Identity: ApplicationPoolIdentity，据我了解，这导致它在 SID 下运行IIS AppPool\AppPoolName
因此，经过一些初步研究和发现，我得出了以下可能性，按从最不优雅到最优雅的顺序排列。我的评论以斜体表示。
将共享移至服务器 A。
这不是我真正想做的——需要对现有服务进行大量重新配置，与其他基础设施不一致。将相关文件夹移动到服务器 B 上具有匿名写访问权限的新共享上。
这至少可以将我的所有共享保留在同一台服务器上，但通过隐藏来实现安全性确实不是我的风格。重新配置 IIS 应用程序以在明确的用户名和密码下运行，并在服务器 B 上复制以授予对文件共享的访问权限。
我认为这至少可以实现我想要的目标，但是改变身份似乎有风险，并且可能给应用程序带来不可预见的后果。为服务器 A 上的应用程序池标识提供用户名和密码的存储凭据，以允许访问服务器 B 上的共享。
不知道这是否真的有效，或者您是否甚至可以将存储的凭据提供给不是完整用户帐户的 SID。这只是一个想法，但我喜欢它，因为它不会影响 IIS 应用程序的现有配置。使用共享上的 ACL 授予对服务器 A 的“机器帐户”的访问权限。
这似乎就像圣杯一样推荐方法（“应用程序池标识也使用机器帐户来访问网络资源”），但当然这些机器没有绑定到 Windows 域，这似乎是使用机器帐户的先决条件。
理想情况下，我希望找到一种黑客或临时解决方案，可以完成第 5 项，或者仅通过重新配置服务器 B 即可授予访问权限的其他方法，同样不需要 AD 域。无论如何，我还想知道更有经验的 Windows Server 管理员在这种情况下会做什么（除了设置该死的 Active Directory 域）。
答案1
在没有 Windows 域的情况下，您唯一的选择就是将应用程序池标识更改为具有访问权限的帐户。如果现有标识没有什么特别之处，您只需创建一个基本用户帐户（不需要配置文件）并将其指定为标识。
在运行时，它将被赋予IIS_IUSRS组并具有与默认应用程序池标识相同的访问权限。