背景
我遇到过这样的情况:开发人员的计算机所处的环境中,IT 部门为用户权限分配策略“以服务登录”设置了强制组策略。该策略设置为强制且不可编辑,因此完全取代了本地设置。
由于这是一台安装了 SQL Server Developer Edition 并运行 IIS 的开发计算机,因此此用户权限由默认 SQL Server 帐户以及应用程序池的虚拟帐户使用(当添加或删除应用程序池时,会动态地添加/删除此用户权限)。如果不将 SQL Server 服务帐户添加到此用户权限,SQL Server 甚至不会启动。
我个人觉得强制 GPO 禁止本地用户权限的默认行为很奇怪。IT 部门添加了一堆管理服务组以及一堆特殊用户组,这些组似乎是作为组织中其他开发部门的变通方法添加的。纯粹从安全角度来看,我还质疑为什么其他开发部门应该获得对我的计算机的“以服务身份登录”访问权限,而他们实际上只是想访问他们的本地计算机。
问题
是否可以以某种方式部署 GPO,以便它仅将服务器设置添加到本地设置而不是替换它们?
是否可以部署 GPO 并仍允许本地用户编辑它?
是否可以以其他方式部署 GPO 以使其不影响本地设置?
是否可以采用一种解决方法,将用户组添加到服务器 GPO,并且开发人员计算机上的本地管理员有权管理并将本地服务帐户添加到该组?
4 中的方法是否适用于应用程序池中的虚拟帐户,或者它们是否需要直接访问用户权限,而不是通过用户组隐式访问?
关于 GPO 中“以服务身份登录”用户权限的最佳实践是什么? IT 部门处理用户权限的方式似乎有点奇怪。
环境
开发者机器:Windows 8.1 Enterprise Eng
AD 服务器:domainControllerFunctionality:5 =(WIN2012);domainFunctionality:4 =(WIN2008R2);forestFunctionality:4 =(WIN2008R2);
不知道这是否表示 Win2008R2 或 Win2012 服务器。
真的很感谢有关 GPO 部署的详细信息以及特定问题的最佳实践和创造性解决方案!
答案1
每个 GPO 都是“强制的”。
问题 1 到 3 的答案都是肯定的“不”。
在这种情况下,我会要求他们为 SQL Server 服务创建用户。这些用户应添加到允许作为服务运行的组中,然后配置本地 SQL 计算机以使用这些凭据运行。
微软有一个威胁和对策指南。查一下。我会把它粘贴在这里。我用的是手机,所以请原谅我没有正确格式化它。
作为服务登录
此策略设置确定哪些服务帐户可以将进程注册为服务。在 Windows Server 2008 R2 和 Windows 7 中,默认情况下只有网络服务帐户具有此权限。任何在单独用户帐户下运行的服务都必须分配此用户权限。
可能的值:用户定义的账户列表/未定义的漏洞
漏洞:以服务身份登录允许帐户启动网络服务或在计算机上持续运行的服务,即使没有人登录到控制台也是如此。只有具有管理权限的用户才能安装和配置服务,从而降低了风险。已经获得该级别访问权限的攻击者可以将服务配置为使用本地系统帐户运行。
对策:根据定义,网络服务帐户具有“作为服务登录”用户权限。此权限不通过组策略设置授予。您应该尽量减少被授予此用户权限的其他帐户数量。
潜在影响:在大多数计算机上,将“作为服务登录”用户权限限制为本地系统、本地服务和网络服务内置帐户是默认配置,不会产生负面影响。但是,如果您安装了可选组件(如 ASP.NET 或 IIS),则可能需要将“作为服务登录”用户权限分配给这些组件所需的其他帐户。IIS 要求将此用户权限明确授予 ASPNET 用户帐户。