我们在自动化应用程序部署方面遇到的最大问题之一是在域服务帐户下运行IIS AppPools和Windows Services是一个“最佳实践”。 不幸的是，这种最佳做法有时会导致部署头痛，因为我们需要快速configuration新的域级服务帐户，或者一旦拥有帐户，我们现在需要pipe理帐户凭证。
我有一个很好的谈话，没有提出域级服务帐户的要求，并有效地采取两种方法之一：
在这两种情况下，似乎更容易pipe理添加一个帐户适当的组/angular色，甚至站起来新的本地帐户，而不是必须提供一个新的域级帐户和pipe理这些凭据。
这将有望缓解ActiveDirectory，Sql Server和Operations团队的pipe理负担，因为不会有更多的密码pipe理 。
我们实际上还没有能够在实践中实现这一点。 我来自一个发展背景，所以我很好奇，这种方法有多less可能会出错？ 我们真的可以摆脱这个方向的域名服务帐户吗？
任何人走过这条道路，我都会感激不尽！
谢谢！
扎克
UPDATE
以前，由于应用程序团队不想存储服务帐户的密码，而且我们真的不在乎他们是什么（我们应该？），所以我们为ActiveDirectory团队提供了一个创build密码散列的实用程序。 所以，当我们需要一个服务帐户，我们会提交请求，他们会回应散列的密码。
在我们的部署脚本（应用程序团队拥有的）中，我们使用密码的任何地方，我们实际上使用了散列。 部署框架知道如何在创build资产时即时解码该散列。
我想，@汤姆指出了我正确的方向。 Windows Server 2008 R2引入了托pipe服务帐户和虚拟服务帐户的概念 。 这个function似乎是我在寻找消除密码pipe理。
查看Scott Forsythe的post托pipe服务帐户（MSA）和虚拟帐户以及TechNet的服务帐户：分步指南了解更多信息。
这里是托pipe服务账户和虚拟账户的并行比较。
托pipe服务帐户的致命弱点是由于某种原因，它们仅限于1台计算机 ？ 这不允许我扩大规模，迫使我重新回到我负责服务账户的传统服务账户模式。 如果我必须这样做，那么添加本地帐户（随机密码，甚至机器帐户）到一个特定的AD组，并映射到Sqlangular色似乎仍然工作？ 我真的希望有经验的人帮助我理解为什么这是不好的 。
我不明白只要我通过其他方式保护该节点，就不允许机器账户networking访问。 例如，只允许通过防火墙的出站服务呼叫到已知的端点，或者其他方式？
否则，托pipe服务帐户和虚拟帐户似乎在function上等同于我所寻找的。
我相信Server 2008提供了一个pipe理服务帐户和自动轮换密码的机制。
编辑：这可能有一些与2008 R2具体。 我似乎还记得在了解架构增强function时阅读了这些内容。