我正在为我们要迁移到的新域构建组策略。在我们当前的环境中，作为服务登录的设置设置在服务器OU 级别 - 在该字段中大约有一百个服务帐户可以访问此权限。
我想将其设置在我们的 OU 树结构的较低位置（我们根据它们运行的应用程序分离出服务器），但我们的一些内部人员根本不想设置此策略。IE：不检查组策略中的设置，让本地服务器处理将哪些帐户放入其本地策略中以进行此设置。我们的内部安全团队希望像我一样设置它，但是不希望设置它的几个人包括一个架构师——因此发生了冲突。
我已经咨询了 Microsoft 高级支持（他们没有给我正式的答复）、内部员工、外部 IT 朋友员工以及数小时的互联网研究 - 但我找不到任何关于是否应该设置此策略的信息。我的直觉是通过 GPO 进行管理，以便可以轻松地从一个地方对其进行审计和管理（我们公司不时进行各种外部审计）。
Microsoft 资源页面：https ://technet.microsoft.com/en-us/library/dn221981.aspx是我能找到的唯一信息，但它说要尽量减少授予此用户权限的帐户数量. 这对我来说似乎有点模棱两可......
有人可以告诉我他们对此设置的看法吗？
您链接的文章解释了作为服务登录提供的权限：
简而言之，您只想将此权限提供给需要它的帐户 - 默认情况下，即本地系统、本地服务和网络服务帐户，因为这些是默认运行的服务。
如果您希望在不同的安全上下文（例如您创建的服务帐户）下运行服务，您需要授予该服务帐户作为服务登录的权限，以便它可以运行您的服务而无需用户已登录。您链接的文章提供了 IIS 和 ASP.NET 作为授予其他帐户此权限的示例；它也适用于作为服务运行的第三方程序。
如果您不想将每个服务都作为 SYSTEM 或 NetworkService 运行，则可以为各个服务设置服务帐户，并为其分配此作为服务登录的权限。以这种方式使用服务帐户的主要优点是，如果您的服务受到威胁，它会在运行它的帐户的安全上下文下运行，而不是 SYSTEM 和 NetworkService 拥有的 SYSTEM 级安全上下文。
因此，最佳做法是仅将此权限分配给运行服务的帐户，并在根据最小权限原则配置的服务帐户下运行单个服务（仅授予他们运行所需的权限；不要授予他们管理员或系统权限）。我要补充一点，通过 GPO 控制它是更安全的方法。如果它在每台服务器上进行本地控制，那么在服务器上获得管理权限的任何人都可以控制哪些帐户可以在该服务器上运行服务，而通过 GPO 强制执行它需要在域级别获得适当的域权限。
“此用户权限在默认域控制器组策略对象 (GPO) 以及工作站和服务器的本地安全策略中定义。默认情况下，没有帐户有权作为服务登录。”
https://technet.microsoft.com/en-us/library/cc957141.aspx
不在该列表中的帐户不应作为服务登录，因此如果您清除列表，您的服务帐户将无法再启动。
我倾向于创建一个服务帐户组并将其放入策略中。它减少了我需要对策略本身进行更改的次数。而且，正如您所说，审核比让它设置服务器到服务器更容易。