LAPS 部署后终端本地管理员密码为何未更新？一次策略应用与事件日志的排查记录

问题背景

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

版本说明：本次部署的是传统 LAPS（Legacy AdmPwd，2015 版），因此下文出现的是 ms-Mcs-AdmPwd、Set-AdmPwdComputerSelfPermission 等旧命名。微软自 2023 年起已把 Windows LAPS 内置进系统，两套方案的 Schema / 属性 / Cmdlet 不通用，选型区别见文末附节。

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

故障现象

密码未轮换：LAPS 管理控制台（Get-AdmPwdPassword）查询多台终端，返回 Password 字段为空或 Expiration 早于当前日期。
事件日志异常：终端本地 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.
策略已应用但密码写不回：gpresult /h 显示 Local Administrator Password Solution 策略出现在「已应用的 GPO」列表中，本地注册表 AdmPwdEnabled = 1（LAPS 客户端已启用），但 AD 上对应计算机对象仍无密码属性——问题出在写回 AD 这一步，而不是策略下发。
域控事件转发缺失：域控 Security 日志中无 LAPS 相关事件（Event ID 4662），无法审计密码读取行为。
部分终端间歇性成功：同一 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（GpoApply）。

附带澄清一个常见误区：不少资料把「Security Filtering 用了 Authenticated Users」当成 LAPS 部署失败的元凶，理由是「计算机账户不在这个组里」。这是错的——域内计算机账户通过机器账号完成域认证，本身就是 Authenticated Users 的成员，用这个组作为过滤条件是可行的、也是官方推荐做法。所以看到 Authenticated Users 不要急着改，先把排查方向转到 AD 对象 ACL 上。

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

在终端本地执行：

1
2


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

返回 AdmPwdEnabled = 1、PasswordLength = 20，说明 LAPS 客户端策略已在本地生效。

再用 gpresult 确认 GPO 命中情况：

1

gpresult /h C:\gpresult.html

LAPS-Client-Policy 出现在「已应用的 GPO」列表里（没有被筛选掉）。这一步很关键：它把问题空间一分为二——

若策略没应用 → 查 GPO 链接、Security Filtering、WMI 筛选器、OU 继承阻断；
若策略已应用（本例）→ 说明下发链路没问题，故障必然在「客户端把密码写回 AD」环节。

本例属于后者，因此后续排查聚焦在 AD 对象权限上，而不是 GPO 作用范围。

步骤 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）指向两个可能方向：

计算机账户无权限将密码写入 AD 对应属性的 ms-Mcs-AdmPwd 与 ms-Mcs-AdmPwdExpirationTime。
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 刷新并让 LAPS 重新上报

权限修好后必须触发一次策略刷新，让 LAPS 客户端重试写回：

在故障终端执行：

1
2
3
4
5


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

3. 验证密码上报成功

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

1

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

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

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

1

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

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

根因分析

根本原因（单因）：Workstations OU 未执行 Set-AdmPwdComputerSelfPermission，导致该 OU 下的计算机账户缺少对自身 ms-Mcs-AdmPwd 与 ms-Mcs-AdmPwdExpirationTime 属性的写入权限。LAPS 客户端以计算机账户身份运行时，把新密码写回 AD 的这一步被 ACL 拒绝，返回 0x80070005 Access is denied，对应事件 ID 2 与事件 ID 13。

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

⚠️ 一个容易误判的点：本次排查中曾把 Security Filtering = Authenticated Users 列为根因之一，理由是「计算机账户不属于该组」——这个判断是错的。域内计算机账户通过机器账号向域认证，本身就属于 Authenticated Users，因此用 Authenticated Users 作为 GPO 的 Security Filtering 不会导致计算机取不到策略；这恰恰是微软文档中 LAPS 客户端策略的推荐配法。定位时应把注意力放在 AD 对象 ACL（Self 写权限），而不是 GPO 作用范围。

为什么部分终端成功？ 这些终端所在 OU 此前已执行过 Set-AdmPwdComputerSelfPermission，计算机账户拿到了 Self 写权限，密码得以正常上报。

把 Security Filtering 从 Authenticated Users 改成显式包含 Domain Computers 仍然可以做，但那是可读性/显式化优化，不是本次故障的修复项——不要把它当成根因写进复盘，否则会误导后来人往错误方向查。

预防措施

权限基线化：在 LAPS 部署 SOP 中明确要求「所有承载终端的 OU 必须执行 Set-AdmPwdComputerSelfPermission」，并纳入变更验收 Checklist。这是本次事故唯一真正的技术修复项，也是新 OU 上线时最容易漏掉的一步。
ACL 周期性巡检：对每个承载终端的 OU 定期导出计算机对象的 ACL，校验 SELF 对 ms-Mcs-AdmPwd / ms-Mcs-AdmPwdExpirationTime 是否有写权限；新增 OU 与 OU 结构调整后必须重跑一次。
事件审计全覆盖：域控必须启用「Directory Service Access」成功/失败审计，并配置 WEF 转发到 SIEM，实现 LAPS 密码读取行为的实时告警。
定期合规巡检：每月执行一次 LAPS 覆盖率巡检脚本，统计「策略已应用但密码未上报」的终端数量，低于 95% 触发告警。
文档与培训：将 LAPS 排查手册（含事件 ID 2/13 的根因与修复命令）纳入桌面运维知识库，并对新员工进行实操培训。

总结

本次 LAPS 部署失败的根源在权限侧：Workstations OU 漏执行 Set-AdmPwdComputerSelfPermission，计算机账户拿不到对自身密码属性的 Self 写权限，密码写回 AD 被 ACL 拒绝，最终导致 35% 终端本地管理员密码未按预期轮换。补齐权限并强制 gpupdate 后，密码在 5 分钟内陆续上报，覆盖率恢复至 100%。

排查过程中还有一个值得记下的反向教训：一开始把矛头指向「GPO Security Filtering 用了 Authenticated Users」，而计算机账户本身就是该组成员，这个方向从一开始就是错的，白绕了一圈。先用 gpresult + AdmPwdEnabled 把「策略有没有下来」和「密码能不能写回」切成两段，再分别查，比凭印象猜配置项快得多。

后续将把「LAPS 覆盖率巡检」纳入每月桌面运维例行任务，并将 OU 权限基线检查固化到变更验收流程中，避免类似合规风险再次发生。

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

附：Legacy LAPS 与 Windows LAPS 怎么选

本文复盘的是传统 Microsoft LAPS（2015 年发布的 AdmPwd 方案），文中的命令与属性名都基于它。需要注意的是，微软自 2023 年 4 月起已在 Windows 客户端/服务器中内置了 Windows LAPS，两套方案在 Schema、属性名和 Cmdlet 上不通用：

维度	Legacy LAPS（AdmPwd）	Windows LAPS（2023+）
来源	需单独下载 MSI 部署客户端	内置于 Win11 22H2+ / Win Server 2022+（通过更新获得）
密码属性	`ms-Mcs-AdmPwd`	`msLAPS-Password`
过期时间属性	`ms-Mcs-AdmPwdExpirationTime`	`msLAPS-PasswordExpirationTime`
授权 Cmdlet	`Set-AdmPwdComputerSelfPermission`	`Set-LapsADComputerSelfPermission`
读取密码	`Get-AdmPwdPassword`	`Get-LapsADPassword`
Schema 扩展	`Update-AdmPwdADSchema`	`Update-LapsADSchema`
密码加密存储	仅支持明文存于 AD 属性	支持 DPAPI-NG 加密，需配合 `msLAPS-EncryptedPassword`
新特性	无	支持密码加密、密码历史、DSC、Azure AD/Entra 集成

选型建议：

全新部署：直接上 Windows LAPS。内置、免装 MSI、支持加密存储，没有理由再从 Legacy 起步。
存量已跑 Legacy：不必急着迁移，两者可以共存（属性名不同，互不覆盖），但应规划迁移窗口。迁移的关键动作是扩展新 Schema（Update-LapsADSchema）、重新授权 OU（Set-LapsADComputerSelfPermission），并切换 GPO 与运维脚本里的 Cmdlet。
本次案例的坑在 Windows LAPS 下同样存在：新方案依旧要求对承载终端的 OU 执行 Self 权限授权，只是 Cmdlet 换成了 Set-LapsADComputerSelfPermission。所以「权限基线化」这条预防措施是跨版本通用的。

如果按本文的命令在 2026 年做全新部署，会发现域控上根本找不到 Set-AdmPwdComputerSelfPermission 这个命令——因为那是 Legacy 模块的东西。这本身就是最容易踩的第一个坑。

延伸阅读

域控与组策略