我们在自动化应用程序部署方面遇到的最大问题之一是，我们认为在域服务帐户下运行 IIS AppPools 和 Windows 服务是一种“最佳实践”。不幸的是，这种最佳实践有时会导致部署问题，因为我们要么需要快速配置一个新的域级服务帐户，要么一旦我们有了帐户，我们现在就需要管理帐户凭据。
我进行了一次很好的讨论，讨论内容是不将域级服务帐户作为要求，而是有效地采取以下两种方法之一：
- 使用计算机帐户（domain\machine$）在节点级别进行保护，并将节点添加到适当的 ActiveDirectory/Sql 组/角色
- 在每台机器上创建本地应用程序特定帐户（machine\myapp），并将该帐户添加到适当的 ActiveDirectory/Sql 组/角色（此处的密码可以根据部署进行更改，无需存储）
在这两种情况下，将帐户添加到适当的组/角色或甚至建立新的本地帐户似乎比配置新的域级帐户并管理这些凭据更容易。
这有望减轻 ActiveDirectory、Sql Server 和运营团队的管理负担，因为不再需要密码管理。
我们实际上还没有在实践中实现这一点。我来自开发背景，所以我很好奇这种方法有多少可能出错？我们真的能用这个方向摆脱域级服务帐户吗？
我将非常感激所有走过这条路的人的想法！
谢谢！
扎克
更新
以前，由于应用程序团队不想存储服务帐户的密码，而且我们真的不关心它们是什么（我们应该关心吗？），所以我们为 ActiveDirectory 团队提供了一个创建密码哈希的实用程序。因此，当我们需要服务帐户时，我们会提交请求，他们会使用哈希密码进行响应。
在我们的部署脚本（由应用团队拥有）中，我们使用密码的任何地方实际上都使用了哈希值。部署框架知道如何在创建资产时动态解码该哈希值。
答案1
我认为 @Tom 为我指明了正确的方向。Windows Server 2008 R2 引入了以下概念：托管服务帐户和虚拟服务帐户。此功能似乎正是我所寻找的消除密码管理的功能。
查看 Scott Forsythe 的帖子托管服务帐户 (MSA) 和虚拟帐户以及 TechNet 的服务帐户：分步指南了解更多信息。
以下是并排比较托管服务帐户与虚拟帐户。
托管服务帐户的致命弱点在于仅限 1 台计算机出于某种原因？这不允许我扩展，并迫使我回到传统的服务帐户模型，在该模型中我负责服务帐户。如果我必须这样做，那么将本地帐户（使用随机密码，甚至机器帐户）添加到特定的 AD 组并将其映射到 Sql Roles 似乎仍然有效？我真的很想让有操作经验的人帮助我理解为什么会这样坏的。
我不明白只要我通过其他方式保护该节点，就不允许机器帐户访问网络意味着什么。例如，仅允许通过防火墙或其他方式向已知端点发出出站服务调用？
否则，托管服务帐户和虚拟帐户在功能上似乎与我所寻找的相同。
答案2
我相信 Server 2008 提供了一种管理服务帐户并自动轮换其密码的机制。
编辑：这可能与 2008 R2 有关。我似乎记得在了解架构增强功能时读过这篇文章。