我正在构build我们要迁移到的新域的组策略。 在我们当前的环境中，“设置为服务login”设置为服务器 OU级别 – 在该字段中有大约一百个服务帐户可以访问该权限。
我想把这个设置在我们的OU树结构的下方（我们根据他们运行的应用程序分离出服务器），但是我们的一些内部员工却不想设置这个策略。 IE：不检查组策略中的设置，并让本地服务器处理为此设置在本地策略中放入哪些帐户。 我们的内部安全团队希望像我这样做，但是那些不想要的人包括build筑师 – 因此冲突。
我已经咨询了微软高级支持（对我没有正式答复），内部员工，外部IT朋友的工作人员以及networking研究小时，但是我根本找不到任何有关这个政策是否应该设置的信息。 我的直觉就是通过GPO来pipe理这个问题，这样可以很容易地从一个地方进行审计和pipe理（我们公司经常进行各种外部审计）。
微软的资源页面： https : //technet.microsoft.com/en-us/library/dn221981.aspx是关于我能find的唯一信息，但它说为了最大限度地减less授予此用户权限的帐户数量。 这对我来说似乎有点模棱两可
有人可以告诉我他们怎么想这个设置？
您链接的文章提供了“ login即服务”提供的权限说明：
即使没有人login到控制台，“作为服务login”用户权限也允许帐户启动在计算机上连续运行的networking服务或服务。
简而言之，您只需要为需要此帐户的帐户提供此权限 – 默认情况下，这就是本地系统，本地服务和networking服务帐户，因为这些帐户是缺省情况下运行的服务。
如果您希望在不同的安全上下文下运行服务 （如您创build的服务帐户），则需要授予该服务帐户“作为服务login”权限，以便它可以运行您的服务而不需要用户login。您链接的文章提供了IIS和ASP.NET作为示例，其中额外的帐户被授予此权利; 它也适用于作为服务运行的第三方程序。
如果您不希望将所有服务都作为SYSTEM或NetworkService运行，则可以为各个服务设置服务帐户，并将它们作为服务login 。 以这种方式使用服务帐户的主要优点是，如果您的服务受到威胁，它将在运行它的帐户的安全上下文中运行，而不是SYSTEM和NetworkService所具有的SYSTEM级安全上下文。
所以，最好的做法是把这个权限只分配给服务运行的账户，并根据最小权限原则configuration的服务账户下运行单个服务（只给予他们运行所需的权限;不要给他们pipe理员或系统权限）。 我会补充说，通过GPO控制这是更安全的方法。 如果在每台服务器上进行本地控制，则任何获得服务器pipe理权限的人都可以控制哪些帐户可以在该服务器上运行服务，而通过GPO实施则需要在域级别获得相应的域权限。
“此用户权限在默认域控制器组策略对象（GPO）和工作站和服务器的本地安全策略中定义。默认情况下，没有帐户具有作为服务login的权限。
https://technet.microsoft.com/en-us/library/cc957141.aspx
不在该列表中的帐户不应该能够以服务身份login，因此，如果清除列表，则带有服务帐户的服务将无法再启动。
我倾向于创build一个服务帐户组，并将其放入策略中。 这减less了我需要更改策略本身的次数。 而且，如你所说，审计比让服务器设置为服务器更容易。