背景
我有一种情况，开发人员计算机处于IT部门为用户权限分配策略“作为服务login”设置强制组策略的环境中。 策略设置为强制且不可编辑，因此完全replace了本地设置。
由于这是一台安装了SQL Server Developer Edition的开发计算机，并且正在运行的IIS，所以默认的SQL Server帐户以及应用程序池的虚拟帐户都使用此用户权限（这些用户权限是dynamic地添加/删除的当应用程序池添加或删除时用户权限）。 没有SQL Server服务帐户添加到此用户权限，SQL Server甚至不会启动。
就个人而言，我觉得有一个强制GPO禁止本地用户权限的默认行为是很奇怪的。 IT部门添加了一大堆pipe理服务组以及一些特殊的用户组，这些组织似乎已被添加为组织中其他开发人员部门的解决方法。 纯粹的安全方面，我也质疑为什么其他开发部门应该在我们的计算机上访问“login即服务”时，他们真的只需要访问本地计算机。
问题
是否可以部署一个GPO的方式，所以它只会将服务器设置添加到本地设置而不是replace它们？
是可以部署一个GPO，仍然让它可以由本地用户编辑？
是否有可能以任何其他方式部署GPO，所以它不会影响本地设置？
它是否可以在解决方法中将用户组添加到服务器GPO，并且开发人员计算机上的本地pipe理员有权访问pipe理本地服务帐户并将其添加到此组？
No 4中的方法是否可以与应用程序池中的虚拟帐户一起工作，还是需要直接访问用户权限，而不是通过用户组隐式地访问？
用户权限“login为服务”的GPO的最佳实践是什么？ 自然而然地，用这个IT部门的方式处理用户似乎很奇怪。
环境
开发人员计算机：Windows 8.1企业工程
AD Server：domainControllerFunctionality：5 =（WIN2012）; domainFunctionality：4 =（WIN2008R2）; 森林function：4 =（WIN2008R2）;
不知道这是否表示Win2008R2或Win2012服务器。
如果有关GPO部署的可能性的详细信息以及特定问题的最佳实践和创造性解决scheme，我们将非常感激！
每个GPO都是“被迫”的。
1到3的答案是一个响亮的NO。
在这种情况下，我会要求他们为SQL Server服务创build用户。 应该将这些用户添加到允许作为服务运行的组中，然后将本地SQL计算机configuration为使用这些凭据运行。
微软有一个威胁和对策指南。 看看。 我将粘贴在这里。 我在移动，所以原谅我没有正确格式化。
作为服务login
此策略设置确定哪些服务帐户可以将进程注册为服务。 在Windows Server 2008 R2和Windows 7中，默认情况下只有networking服务帐户具有此权限。 任何在单独用户帐户下运行的服务都必须分配此用户权限。
可能的值：用户定义的帐户列表/未定义的漏洞
漏洞：作为服务login，即使没有人login到控制台，帐户也可以启动在计算机上连续运行的networking服务或服务。 只有具有pipe理权限的用户才能安装和configuration服务，从而降低了风险。 已经达到该访问级别的攻击者可以将该服务configuration为使用本地系统帐户运行。
对策：根据定义，networking服务帐户具有作为服务login的用户权限。 此权利不通过组策略设置授予。 您应该尽量减less授予此用户权限的其他帐户的数量。
潜在影响：在大多数计算机上，限制作为服务用户login本地系统，本地服务和networking服务内置帐户的权限是默认configuration，并且没有负面影响。 但是，如果安装了可选组件（如ASP.NET或IIS），则可能需要将“作为服务login”用户权限分配给这些组件所需的其他帐户。 IIS要求将此用户权限明确授予ASPNET用户帐户。