我刚刚花了今天上午的大部分时间与供应商进行支持通话，最终我们通过手动将其应用程序使用的服务帐户添加到Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/User Rights Assignment域 GPO 设置的以下策略中解决了我们的问题：
- 备份文件和目录
- 作为批处理作业登录
- 恢复文件和目录
重新启动服务器并获取更新的 GPO 后，我们的服务帐户在尝试启动应用程序时不再生成以下事件 4625 - 登录类型 4 审核事件：
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 7/22/2013 9:27:04 AM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: server.constco.com
Description:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: server$
Account Domain: constco
Logon ID: 0x3e7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: service-account
Account Domain: constco
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xc000015b
Sub Status: 0x0
供应商的文档指示我们将服务帐户添加到备份操作员和高级用户本地组 - 我们照做了。阅读每个所需用户权限分配策略的“解释”选项卡表明备份操作员默认拥有这些权限（TechNet 似乎证实了这一点这)。顺便说一句，我找不到任何关于为高级用户分配这些权利的提及，所以我不太清楚为什么这是一个要求。
为什么我们必须明确地为该服务帐户分配这些权利（
Back up files and directories、Log on as a batch job、Restore files and directories），而它作为备份操作员本地组的成员就应该拥有这些权利？用户权限策略和内置本地组之间有什么关系？用户权限策略是构成每个内置本地组的“元”权限的组成部分吗？如果是，我在哪里可以找到哪些权限属于哪些内置本地组？
如上所述，我们通过将服务帐户添加到组策略对象来解决此问题，该对象手动为许多服务帐户分配这些特定权限。我从供应商的工程师那里得到的感觉是，这个 GPO 正在干扰这些组成权限到本地组的映射。这个预感正确吗？以这种方式分配组成用户权限是不是一个坏主意 (TM)？
答案1
本地内置组（以及域组）的成员拥有分配给该组的任何权限。服务器上本地内置组的默认权限在本地安全设置中设置。要访问本地安全设置，请单击“开始”，键入 secpol.msc 并按 Enter。在本地安全策略编辑器中，展开“本地策略”，然后单击“用户权限分配”。您将在那里看到哪些组/用户被授予了哪些权限。
本地用户权限分配设置可被域组策略覆盖。如果您创建了授予特定组/用户特定权限（如“以批处理作业登录”）的域组策略，这将覆盖用户拥有该权限的本地策略。
根据您所写的内容，我猜测发生了以下情况：您的域中有一个 GPO，它授予某些用户您提到的权限。此策略未将这些权限授予本地计算机备份操作员组。此策略覆盖了服务器上的默认策略。因此，将用户添加到备份操作员组并没有赋予他们这些权限，因为由于域 GPO，备份操作员没有这些权限。
至于供应商的解决方案是否是个好主意：我发现使用组织良好的组来管理权限通常比将权限授予单个帐户更容易。这样，当您添加新用户时，您会将用户添加到他所属的逻辑组中，并且他将立即拥有所需的所有权限，而不必逐一为他分配每个权限。这就是内置组的目的。
您不必将这三项权限授予单个用户，而是可以在 GPO 中将这三项权限授予“备份操作员”组。然后将用户添加到该组即可获得预期效果。
我很好奇为什么你首先要有一个域策略来管理这些权限。如果目的是授予某些用户执行备份操作的权限，那么使用域内置的备份操作员组可能是一个更好的主意。