问题背景

公司为满足等保 2.0 与内控要求，计划在 Windows 域环境中统一部署 Microsoft LAPS（Local Administrator Password Solution），实现终端本地管理员密码的自动轮换与集中托管。IT 团队已完成 LAPS Schema 扩展、GPO 策略配置与客户端推送，预期所有域内 Windows 10/11 终端将在 24 小时内完成首次密码上报与轮换。

然而，策略推送后一周，抽查发现仍有约 35% 的终端本地管理员密码未更新，LAPS 管理控制台中对应计算机对象无密码记录。安全审计要求「本地管理员密码必须 7 天内完成首次轮换」，当前状态已构成合规风险。需要快速定位策略应用失败的根因，并给出可落地的修复方案。

故障现象

1. 密码未轮换：LAPS 管理控制台（Get-AdmPwdPassword）查询多台终端，返回 Password 字段为空或 Expiration 早于当前日期。
2. 事件日志异常：终端本地 Applications and Services Logs\Microsoft\Windows\LAPS\Operational 日志中频繁出现：
   • Event ID 2：Password update failed. Error: Access is denied.
   • Event ID 13：Policy application failed. The password could not be stored in Active Directory.
3. GPO 应用不完整：gpresult /h 显示 Local Administrator Password Solution 策略已应用，但 AdmPwdEnabled 注册表项仍为 0（未启用）。
4. 域控事件转发缺失：域控 Security 日志中无 LAPS 相关事件（Event ID 4662），无法审计密码读取行为。
5. 部分终端间歇性成功：同一 OU 下的终端，约 65% 已成功上报密码，35% 持续失败，无明显机型或镜像差异。

排查过程

步骤 1：确认 LAPS 客户端版本与策略下发

在故障终端执行：

1
2
3

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Where-Object { $_.DisplayName -like "*LAPS*" } |
  Select-Object DisplayName, DisplayVersion, Publisher

返回版本为 6.2.0.0，与域控推送的 MSI 一致，排除客户端版本过旧问题。

检查 GPO 是否正确链接到终端所在 OU：

1

Get-GPO -Name "LAPS-Client-Policy" | Get-GPOReport -ReportType XML

发现策略已链接到 OU=Workstations,DC=corp,DC=local，但 Security Filtering 中仅包含 Authenticated Users，未单独授予 Domain Computers 读取权限。

步骤 2：检查 LAPS 注册表与策略应用状态

在终端本地执行：

1
2

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft Services\AdmPwd" |
  Select-Object AdmPwdEnabled, PasswordAgeDays, Complexity, PasswordLength

关键发现：AdmPwdEnabled 值为 0，表示 LAPS 策略未在本地生效。正常情况下 GPO 应用后该值应为 1。

进一步检查 gpresult /h C:\gpresult.html 中的「已应用策略」列表，发现 LAPS-Client-Policy 出现在「筛选后拒绝」列表，原因是 GPO 的 Security Filtering 未包含计算机账户。

步骤 3：分析 LAPS 事件日志定位失败原因

导出 LAPS Operational 日志：

1
2
3

Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" |
  Where-Object { $_.LevelDisplayName -eq "Error" } |
  Select-Object TimeCreated, Id, Message -First 10

关键错误：

1
2
3

Event ID 2: Password update failed. Error: Access is denied. (0x80070005)
Event ID 13: Policy application failed. The password could not be stored in Active Directory.
              Extended error: Insufficient access rights to perform the operation.

错误码 0x80070005（Access Denied）指向两个可能方向：

1. 计算机账户无权限将密码写入 AD 对应属性的 ms-Mcs-AdmPwd 与 ms-Mcs-AdmPwdExpirationTime。
2. LAPS 客户端尝试以 SYSTEM 身份访问注册表或文件系统受限资源失败。

步骤 4：验证计算机账户在 AD 中的权限

在域控上执行：

1
2
3

$computer = Get-ADComputer "WS-DEV-042" -Properties "ms-Mcs-AdmPwd", "ms-Mcs-AdmPwdExpirationTime"
$acl = Get-Acl "AD:$($computer.DistinguishedName)"
$acl.Access | Where-Object { $_.IdentityReference -like "*WS-DEV-042*" }

发现计算机账户 WS-DEV-042$ 仅拥有默认的 Self 权限（允许修改自身部分属性），但缺少对 ms-Mcs-AdmPwd 属性的写入权限。

LAPS 官方文档要求：所有需要托管密码的计算机账户，必须被显式授予对 ms-Mcs-AdmPwd 与 ms-Mcs-AdmPwdExpirationTime 的写入权限。当前域环境中仅对部分 OU 执行了 Set-AdmPwdComputerSelfPermission，遗漏了 Workstations OU。

步骤 5：检查事件转发与审计配置

LAPS 要求域控开启「对象访问」审计策略，并配置事件转发到 SIEM。检查发现：

1

auditpol /get /subcategory:"Directory Service Access"

返回 Failure auditing 未启用，导致域控 Security 日志中无 Event ID 4662（对象访问失败），无法审计 LAPS 密码读取行为。

解决方案

1. 修复计算机账户权限（最关键）

在域控 PowerShell 中执行（针对遗漏的 OU）：

1

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Workstations,DC=corp,DC=local"

该命令会为 OU 下所有计算机账户添加对 ms-Mcs-AdmPwd 与 ms-Mcs-AdmPwdExpirationTime 的写入权限。执行后等待 15 分钟 GPO 刷新周期。

2. 修正 GPO Security Filtering

将 LAPS-Client-Policy 的 Security Filtering 从 Authenticated Users 改为显式包含 Domain Computers 组：

1
2

Set-GPPermission -Name "LAPS-Client-Policy" -TargetName "Domain Computers" `
  -TargetType Group -PermissionLevel GpoApply

3. 强制 GPO 刷新与 LAPS 策略应用

在故障终端执行：

1
2
3
4
5

gpupdate /force
Invoke-Command -ScriptBlock {
  Start-Service -Name "LAPS"
  Restart-Service -Name "gpsvc"
}

4. 验证密码上报成功

等待 5 分钟后，在域控执行：

1

Get-AdmPwdPassword -ComputerName "WS-DEV-042"

确认返回非空 Password 与 Expiration 字段。

5. 开启域控对象访问审计（合规要求）

1

auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable

并配置 Windows Event Forwarding（WEF）将域控 Security 日志转发到 SIEM 平台。

根因分析

根本原因：LAPS GPO 的 Security Filtering 配置为 Authenticated Users，而计算机账户在默认情况下不属于该组，导致策略未应用到终端；同时 Workstations OU 未执行 Set-AdmPwdComputerSelfPermission，计算机账户缺少写入 ms-Mcs-AdmPwd 属性的权限，密码上报失败。

次要原因：域控「Directory Service Access」审计策略未启用，无法通过事件日志快速定位权限拒绝事件。

为什么部分终端成功？ 这些终端所在 OU 此前已执行过 Set-AdmPwdComputerSelfPermission，且 GPO 链接的 Security Filtering 包含了对应计算机组。

预防措施

1. 权限基线化：在 LAPS 部署 SOP 中明确要求「所有承载终端的 OU 必须执行 Set-AdmPwdComputerSelfPermission」，并纳入变更验收 Checklist。
2. GPO Security Filtering 标准化：LAPS 客户端策略统一使用 Domain Computers 组作为 Security Filtering，避免依赖 Authenticated Users 的隐式行为。
3. 事件审计全覆盖：域控必须启用「Directory Service Access」成功/失败审计，并配置 WEF 转发到 SIEM，实现 LAPS 密码读取行为的实时告警。
4. 定期合规巡检：每月执行一次 LAPS 覆盖率巡检脚本，统计「策略已应用但密码未上报」的终端数量，低于 95% 触发告警。
5. 文档与培训：将 LAPS 排查手册（含事件 ID 2/13 的根因与修复命令）纳入桌面运维知识库，并对新员工进行实操培训。

总结

本次 LAPS 部署失败的根源在于 GPO Security Filtering 配置不当与计算机账户权限缺失，导致 35% 终端本地管理员密码未按预期轮换。通过修复 Set-AdmPwdComputerSelfPermission、调整 GPO 权限过滤、强制 gpupdate 并开启域控审计，问题在 2 小时内收敛。后续将把「LAPS 覆盖率巡检」纳入每月桌面运维例行任务，并将权限基线检查固化到变更验收流程中，避免类似合规风险再次发生。

经验提炼：企业级密码托管方案的落地，不仅依赖技术选型，更依赖权限模型的正确配置与审计链路的完整性。LAPS 看似简单的「自动轮换」，背后涉及 AD Schema 扩展、GPO 权限、计算机自权限、事件审计四大环节，缺一不可。