Windows域环境里，最容易被忽略但又最致命的安全短板，往往是那些被赋予了高权限的服务账号。这些账号运行着SQL Server、备份系统、中间件或者各类运维脚本，一旦被拿下，攻击者就能在域内横行。直接说结论：通过AD域组策略对关键服务账号实施精细化管控，是成本最低、见效最快的防御手段之一。下面直接拆解具体怎么落地。

锁定服务账号的底层逻辑

很多人以为把服务账号密码设得足够复杂、定期轮换就算安全了。其实远远不够。服务账号的风险点在于，它们通常需要“作为服务登录”的权限，且往往被授予了本地管理员甚至域管理员权限。攻击者一旦通过哈希传递、票据伪造或者凭据转储拿到这个账号的凭证，就能以极高的权限横向移动。因此，锁定的核心思路不是单纯改密码，而是从登录能力、权限范围、审计颗粒度三个维度同时收紧。

第一步：利用“作为服务登录”权限精准管控

默认情况下，把账号加入本地管理员组再注册为服务，系统会自动授予“作为服务登录”权限。但这个权限可以被集中管理。打开组策略管理控制台，找到“计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 用户权限分配”，定位到“作为服务登录”。这里不要留白，也不要塞进“Domain Users”这种宽泛的组。只把经过审批的、有明确业务归属的服务账号显式添加进去。任何未在此列表中的账号尝试注册服务，都会被系统直接拒绝，哪怕它有本地管理员权限。这一步能直接阻断攻击者用窃取的高权限账号创建恶意服务。

第二步：通过“拒绝作为服务登录”进行反向锁定

有些场景下，你需要更极端的控制。比如某个OU里的服务器只允许特定几个服务账号运行，其余一律禁止。这时候就用“拒绝作为服务登录”策略。在同一路径下找到该设置，把那些你明确知道不该在这些机器上运行服务的账号或者安全组加进去。注意，这个策略的优先级高于允许策略。如果你把“Domain Admins”组加进拒绝列表，那么即便是域管理员也无法在这些服务器上注册服务，这能有效防止管理员凭据被滥用后直接植入后门服务。

第三步：强制服务账号绑定特定计算机

服务账号的漫游能力是巨大的安全隐患。一个在数据库服务器上使用的服务账号，不应该能登录Web服务器。在AD用户和计算机里，打开服务账号的属性，找到“账户”选项卡，点击“登录到”。默认是“所有计算机”，把它改成一张明确的白名单，只允许该账号登录到它必须运行的那几台服务器。这个设置会直接作用于Kerberos认证过程，如果账号试图从白名单外的机器请求TGT票据，域控会直接拒绝。这比任何事后告警都来得直接。

第四步：通过组策略首选项精准管理本地组成员

服务账号经常被塞进本地管理员组，但很多人用脚本或者手工添加，时间一长就失控了。用组策略首选项来管理本地组成员是更可靠的方式。在组策略编辑器中，进入“计算机配置 → 首选项 → 控制面板设置 → 本地用户和组”。新建一条“本地组”策略，操作选择“更新”，组名选择“Administrators (内置)”。在成员列表里，只添加那些确需本地管理员权限的服务账号。勾选“删除所有成员用户”和“删除所有成员组”可以把之前散乱的权限一把清干净，然后重新建立秩序。这样每次组策略刷新时，系统都会强制把本地管理员组重置为你定义的状态，任何被偷偷添加的账号都会被自动剔除。

第五步：用高级审核策略记录服务账号的一举一动

权限收紧之后，审计必须跟上。在同一个组策略对象中，进入“计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置 → 审核策略”。重点开启以下几项：审核登录事件（成功和失败）、审核账户管理事件（成功和失败）、审核凭据验证（成功和失败）。对于服务账号，尤其要关注事件ID 4624（登录成功）中的登录类型5（服务），以及事件ID 4672（分配了特殊权限）。把这些日志集中转发到SIEM或日志收集服务器，建立基线后，任何偏离正常模式的行为——比如服务账号在非业务时间登录、从非白名单机器登录——都能快速触发告警。

第六步：通过受限制的组策略锁定高权限组

这是一个容易被忽视的强力设置。在“计算机配置 → Windows 设置 → 安全设置 → 受限制的组”中，可以定义哪些域账号或域组必须（或不得）属于某个本地组。比如，你可以强制规定只有“DB_Service_Admins”这个域组可以加入服务器的本地管理员组，而“Domain Admins”虽然权限高，但在这里被显式排除。这样即使域管理员被拿下，攻击者试图用域管账号直接登录数据库服务器时，会发现该账号在本地管理员组里根本不存在，权限被大幅削弱。这个策略每90分钟刷新一次，且一旦应用，手动修改会在下次刷新时被强制回退。

第七步：服务账号密码策略的差异化处理

域级别的密码策略对所有账号一视同仁，但服务账号需要更严格的密码要求。可以通过精细化的密码策略（PSO）来实现。在Active Directory管理中心里，为服务账号所在的OU或组创建单独的密码设置对象。把密码长度拉到至少20位以上，复杂度要求全部开启，更重要的是，把“最短密码期限”设置为0天，这样一旦怀疑密码泄露，可以立即轮换而不受策略限制。同时，对于高权限服务账号，建议启用“使用可逆加密存储密码”的禁用策略，尽管这会影响到某些老旧应用，但从安全角度必须禁用。

第八步：结合服务主体名称（SPN）进行Kerberos硬化

服务账号通常注册了SPN，这是Kerberos认证的必要条件，也是Kerberoasting攻击的目标。在锁定服务账号时，要检查其SPN注册情况。用setspn -L 服务账号名列出所有SPN，确认每个SPN都是业务必需的，多余的立即删除。同时，对于运行关键服务的账号，考虑启用“此账户支持Kerberos AES 256位加密”选项，并禁用RC4加密。这能有效提高攻击者离线破解TGS票据的难度。这些设置可以在账号属性中的“账户”选项卡里找到。

第九步：通过组策略禁止服务账号的交互式登录

服务账号天生不需要交互式登录。在组策略中，进入“计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 用户权限分配”，找到“拒绝本地登录”和“拒绝通过远程桌面服务登录”。把所有的关键服务账号都加进去。这样即使攻击者拿到了服务账号的明文密码或哈希，也无法直接登录到服务器的桌面环境，只能通过服务上下文来操作，攻击面被大幅压缩。同时，在“拒绝从网络访问此计算机”中，也可以考虑加入服务账号，防止它们被用于网络共享访问。

第十步：定期自动化审计与基线对比

上述策略部署后，必须建立定期审计机制。可以编写PowerShell脚本，每周自动导出关键组策略设置、本地组成员、服务账号登录事件，并与安全基线进行对比。以下是一段用于检查特定服务账号是否被正确限制登录计算机的脚本片段：

# 检查服务账号的登录工作站限制
$serviceAccount = "svc_sql_prod"
$user = Get-ADUser -Identity $serviceAccount -Properties UserWorkstations
if ($user.UserWorkstations -eq $null -or $user.UserWorkstations -eq "") {
    Write-Warning "$serviceAccount 未设置登录工作站限制！"
} else {
    Write-Host "$serviceAccount 已限制登录到: $($user.UserWorkstations)"
}

这段脚本可以集成到定期任务中，对账号状态进行持续监控。任何偏离基线的配置变更都应在第一时间触发告警并启动应急流程。

落地时的常见坑与对策

在实际操作中，最大的阻力往往来自业务方。服务账号被锁定后，某些老旧应用可能因为硬编码了账号权限或登录行为而异常。应对方法是先在测试OU中镜像生产环境的策略，用一周时间观察事件日志中的“审核失败”记录，逐条与业务方确认后，再逐步推向生产。另一个坑是组策略继承和优先级冲突。务必使用gpresult /h report.html命令在目标服务器上生成策略结果集报告，确认最终生效的策略符合预期。如果发现Domain Admins被意外拒绝服务登录，要立即排查是否在更高层级的GPO中设置了拒绝策略。

锁定关键服务账号不是一次性项目，而是一个持续收紧的过程。每次业务变更、每次新增服务账号，都要走审批流程并同步更新组策略配置。把上述步骤固化为安全基线，配合自动化审计，才能让Windows服务器的AD域环境真正具备对高级持续性威胁的抵抗力。