我正在和一个10名开发人员一起工作。 我们有服务器设置，执行备份，软件自动化构build，自动化部署等等。 其中一些服务器包含检测材料，例如生产系统的login详细信息（这是自动部署所必需的）。
我们想限制谁可以访问这些机器，以减less意外泄漏密码的风险。 为此，我们在Active Directory中创build了一个包含4个人的组，他们被允许访问包含敏感资料的服务器，并确保只有这4个用户可以login。
其中一些服务器运行计划任务和Windows服务来执行备份/部署。 这些任务/服务在特定的“共享”用户帐户下运行，我们称之为“buildacc”。 原因是这些任务需要访问networking中的共享资源才能执行构build/部署。 所以我们也给了这个用户对服务器的访问权限。
为了能够修改Windows中的计划任务，所有4个开发人员都需要访问这个“buildacc”账户，这意味着他们都必须知道共享密码，并告诉对方何时改变，我们不喜欢这个想法的。
我们考虑过使用个人帐户来运行预定的任务，例如build立脚本。 我们看到的缺点是，团队中的任何成员都可以更改构build脚本，并使其在configuration实际计划任务的用户帐户下执行新的操作。
如何处理这种情况是否有最佳做法？
假设您使用的是Windows 2008R2系统和2008R2 AD，则可以使用托pipe服务帐户进行此操作。
这个technet博客条目有一个很好的总结如何使用托pipe服务帐户，但是，这里是基本的原则：
托pipe服务帐户是与计算机紧密相连的AD帐户，具有自动pipe理的密码。 您不需要创build密码，也不需要知道密码，但是由于它是一个AD帐户，因此您可以将其用于networkingACL，从而使其适合您的场景。
但是，为计划任务使用MSA将要求您使用命令行来创build您的任务（有关更多详细信息，请参阅此线程和此线程）。
总的来说，你在前面做的很好。 一个专门的“服务”风格的帐户，它设置了所需的权限，并用于运行计划的任务。
在这一点上，你真正需要做的是：
buildacc 在这一点上，这只是一个内部政策问题。 您应该设置计划任务，以便它们不会真正改变。 这意味着如果它正在运行“test.exe”，然后让开发人员修改该exe文件，但不是计划的任务本身。 如果所有的开发人员真的需要改变计划的任务，那么你只是卡在你身边…
编辑：我也会告诫你在服务和服务器上对你的buildacc账户过于自由。 最好严格保留“build设”，备份和其他服务在自己的专用帐户下运行。
我看到几个答案提到MSA作为用于运行计划任务的帐户的解决scheme，但正如本文作者所述，他们使用Windows Server 2008 R2，根据我的研究， 此操作系统上的MSA不能用于运行计划的任务 。
但是，在Windows Server 2012中，可以使用gMSA（组托pipe服务帐户）来运行计划任务，如本文所述 。