10.1 先分清：事件发生在哪里#

⚠️ 查不到事件不等于事件一定没发生。 还可能是查错机器、审计策略未启用、事件已被覆盖、时间范围选错，或者事件发生在另一台 DC。先确定日志位置与审计范围，再解释“没有结果”。

10.2 查询账户锁定：4740#

先按日志名与事件 ID 在服务端过滤，只取最近 20 条：

1
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20 |
2
    Select-Object -First 2 TimeCreated,Id,LevelDisplayName
3

4
TimeCreated         Id LevelDisplayName
5
-----------         -- ----------------
6
2026/9/9 10:02:30 4740 信息
7
2026/9/9 10:01:19 4740 信息

上面是 QYNET-CORE01 实机输出节选。“信息”是事件级别，并不表示账户锁定是好事；要按 Id 和事件字段判断。若只想看最近一小时，可加 StartTime=(Get-Date).AddHours(-1)，避免遍历过多旧事件：

1
Get-WinEvent -FilterHashtable @{
2
    LogName   = 'Security'
3
    Id        = 4740
4
    StartTime = (Get-Date).AddHours(-1)
5
} -ErrorAction SilentlyContinue
6

7
# 本次查询时间段没有匹配的 4740，命令无输出

1
$event = Get-WinEvent -FilterHashtable @{
2
    LogName = 'Security'
3
    Id      = 4740
4
} -MaxEvents 1
5

6
$data = @{}
7
([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
8
    $data[$_.Name] = $_.InnerText
9
}
10

11
[pscustomobject]@{
12
    TimeCreated        = $event.TimeCreated
13
    LockedAccount      = $data['TargetUserName']
14
    CallerComputerName = $data['TargetDomainName']
15
}
16

17
TimeCreated        : 2026/9/9 10:02:30
18
LockedAccount      : qianyue
19
CallerComputerName : QYNET-USER01

10.3 查询登录失败：4625#

1
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
2
    Select-Object -First 2 TimeCreated,Id,LevelDisplayName
3

4
TimeCreated          Id LevelDisplayName
5
-----------          -- ----------------
6
2026/9/23 15:00:57 4625 信息
7
2026/9/23 15:00:57 4625 信息

以上为实机输出节选。这两条最近记录的 LogonType 是 5（服务登录），TargetUserName 为 -，状态码为 0xC000018D；不能把任何一条 4625 都解释成“用户输错密码”。

排查时至少核对：

同样可以从 XML 取字段，避免按语言拆分 Message：

1
$event = Get-WinEvent -FilterHashtable @{
2
    LogName = 'Security'
3
    Id      = 4625
4
} -MaxEvents 1
5

6
$data = @{}
7
([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
8
    $data[$_.Name] = $_.InnerText
9
}
10

11
[pscustomobject]@{
12
    TimeCreated = $event.TimeCreated
13
    Account     = $data['TargetUserName']
14
    LogonType   = $data['LogonType']
15
    Status      = $data['Status']
16
    SubStatus   = $data['SubStatus']
17
    Process     = $data['ProcessName']
18
}
19

20
TimeCreated : 2026/9/23 15:00:57
21
Account     : -
22
LogonType   : 5
23
Status      : 0xc000018d
24
SubStatus   : 0xc000018d
25
Process     : C:\Windows\System32\svchost.exe

以上为实机输出。日志级别 LevelDisplayName 是“信息”，但事件 ID 与 Status 表明这是登录失败。

10.4 查目录服务与 DFSR：别用英文级别名称硬匹配#

原始思路是“取最近 50 条，再找错误/警告”，但下面的写法在中文 Windows 上不可靠：

1
# 不推荐：本机的 LevelDisplayName 实际显示“错误”“警告”，不是 Error/Warning
2
Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 |
3
    Where-Object { $_.LevelDisplayName -eq 'Error' }

LevelDisplayName 会本地化。若仍想按“最近 50 条”筛选，应使用不受显示语言影响的数值 Level：2 是错误，3 是警告。

1
Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 |
2
    Where-Object { $_.Level -eq 2 } |
3
    Select-Object -First 3 TimeCreated,Id,LevelDisplayName
4

5
TimeCreated          Id LevelDisplayName
6
-----------          -- ----------------
7
2026/9/23 16:00:40 1863 错误
8
2026/9/23 16:00:40 1863 错误
9
2026/9/23 16:00:40 1863 错误

以上是实机输出节选。事件 1863 描述的是某些目录分区在配置的延迟间隔内未收到复制信息。这里应先核对复制状态，而不是只根据事件 ID 推断根因。

DFSR 同理：

1
Get-WinEvent -LogName 'DFS Replication' -MaxEvents 50 |
2
    Where-Object { $_.Level -in 2,3 } |
3
    Select-Object -First 3 TimeCreated,Id,LevelDisplayName
4

5
TimeCreated          Id LevelDisplayName
6
-----------          -- ----------------
7
2026/9/23 16:35:37 5008 错误
8
2026/9/23 15:32:54 5008 错误
9
2026/9/23 15:16:32 5008 错误

以上为实机输出节选。其中一条 5008 指向 SYSVOL 的复制伙伴 QYNET-CORE02，错误为 1722：RPC 服务器不可用。它与复制健康篇中的 RPC 排障相连；不能只靠日志 ID 判断是网络、DNS、防火墙还是伙伴没有启动。

💡 两种筛选语义不同：-MaxEvents 50 | Where-Object Level ... 是“最近 50 条里有多少错误”；-FilterHashtable @{LogName='...'; Level=2} 是“先找错误，再取最近若干条”。后者通常更适合大日志，但会找到更早的错误，不能误称为“最近 50 条中的错误”。

10.5 4625、4771、4776：不要混为一谈#

不是“Kerberos 密码错只看 4771，NTLM 密码错只看 4776，因此 4625 没用”。同一次尝试可能在不同机器和认证阶段留下不同事件；是否出现仍取决于实际协议、审计配置与日志保留情况。

查询近期 Kerberos 预认证失败：

1
$preAuthFailures = @(Get-WinEvent -FilterHashtable @{
2
    LogName = 'Security'
3
    Id      = 4771
4
} -MaxEvents 20 -ErrorAction SilentlyContinue)
5

6
$preAuthFailures.Count
7

8
0

这是当前 VM 的实际结果：没有查到 4771，所以本文不会编造一条 4771 实机输出。若在别的环境遇到 4771，重点看 FailureCode：

⚠️ 原大纲把“过期”都归到 0x12，不够准确；密码过期还应留意 0x17。0x25 是很强的时间线索，但仍要结合事件上下文验证，不要只改时钟而不查来源。

本机能查到 4776，但最近的验证是成功而不是失败：

1
$event = Get-WinEvent -FilterHashtable @{
2
    LogName = 'Security'
3
    Id      = 4776
4
} -MaxEvents 1
5

6
$data = @{}
7
([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
8
    $data[$_.Name] = $_.InnerText
9
}
10

11
[pscustomobject]@{
12
    Account = $data['TargetUserName']
13
    Status  = $data['Status']
14
}
15

16
Account       : Administrator
17
Status        : 0x0

因此 4776 的表格说明应写“NTLM 凭据验证”，不能一律写成“NTLM 凭据验证失败”。

10.6 4648：显式凭据不等于横向移动#

4648 表示进程显式指定另一账户的凭据尝试登录。runas、计划任务或管理工具均可能正常触发。当前实验 VM 中就有一条来自 VMware Tools 的记录：

1
$event = Get-WinEvent -FilterHashtable @{
2
    LogName = 'Security'
3
    Id      = 4648
4
} -MaxEvents 1
5

6
$data = @{}
7
([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
8
    $data[$_.Name] = $_.InnerText
9
}
10

11
[pscustomobject]@{
12
    Subject = $data['SubjectUserName']
13
    Target  = $data['TargetUserName']
14
    Process = $data['ProcessName']
15
}
16

17
Subject : QYNET-CORE01$
18
Target  : Administrator
19
Process : C:\Program Files\VMware\VMware Tools\vmtoolsd.exe

以上是实机输出。单条 4648 不是入侵证据。若非管理工作站在短时间内大量触发、进程异常，或同时出现可疑远程登录与资源访问，再结合进程路径、目标账户、目标服务器、4624/4625 等事件调查。

10.7 常用安全事件 ID 速查#

💡 审计是前提。 4662、5136 尤其依赖对应的高级审计策略与对象 SACL；没有记录不能证明对象一定未被操作。排障时也要注意日志覆盖和采集时间窗。

10.8 本次 VM 的真实排障线索：历史事件与当前状态#

这次没有主动制造故障，但从日志看到以下历史线索：

历史事件不能单独证明故障现在仍存在，于是又做了一次只读的当前状态检查：

1
repadmin /replsummary
2

3
源 DSA              最大增量         失败/总数 %%     错误
4
QYNET-CORE02      06d.23h:04m:28s    5 /   5  100  (1722) RPC 服务器不可用。
5

6
目标 DSA            最大增量         失败/总数 %%     错误
7
QYNET-CORE01      06d.23h:04m:28s    5 /   5  100  (1722) RPC 服务器不可用。
8

9
尝试检索复制信息时遇到以下操作错误:
10
58 - QYNET-CORE02.qy.net

这是 2026/9/24 10:58 的实机输出节选。它确认当时复制仍不健康，而不只是“昨天报过一次错”。本次 vmrun list 仅看到 QYNET-CORE01 运行；QYNET-CORE02 未在运行 VM 列表中。这支持优先核对 DC02 的运行状态和网络，但仍不能仅凭 VMware 列表排除它在别的宿主机运行或得出全部根因。

这里不执行强制复制、FSMO seize、清理元数据等变更操作。待 DC02 的运行状态与连接方式明确后，再按第五篇：复制健康和第六篇：DCDiag逐项验证。

10.9 本节记忆卡#

1. 先找机器，再找日志和 ID：4625 在登录目标机，4771/4776 看负责验证的 DC。
2. 4740 看调用方计算机名；其 XML 对应字段是 TargetDomainName，不要按想象写 CallerComputerName。
3. 中文 Windows 不用 LevelDisplayName -eq 'Error'；用 Level -eq 2，警告用 3。
4. 4776 可以成功，4648 可以是正常操作；事件 ID 不能脱离字段和上下文定性。
5. 历史日志 + 当前复测 才能判断问题是否仍在；查到 1722 后从伙伴运行状态、DNS、网络、RPC 与服务继续排查。

参考资料#

• Microsoft Learn：4740 账户锁定字段
• Microsoft Learn：4625 登录失败事件
• Microsoft Learn：4771 Kerberos 预认证失败与代码
• Microsoft Learn：4648 显式凭据事件
• Microsoft Learn：目录服务更改审计

上一篇：Windows AD PowerShell（九）：时间同步

下一篇：Windows AD PowerShell（十一）：备份与恢复