一、域控时间同步源梳理与修复#

定位 PDC 主时钟源、检查域内 NTP 层级漂移，排查所有 DC 的时间误差来源，修正 GPO 时间同步配置。近一周若总是域认证偶发失败，这是高嫌疑方向。

1
# 全 DC 时间偏差一览（在管理机上对每台 DC 轮询）
2
w32tm /stripchart /computer:QYNET-CORE01 /samples:3
3
w32tm /stripchart /computer:QYNET-CORE02 /samples:3
4
# 域内时间层级是否健康
5
w32tm /monitor /domain:qy.net

1
netdom query fsmo
2
w32tm /query /status /verbose
3
w32tm /query /configuration
4
w32tm /query /peers

1
# 仅在林根域 PDC 上配置经过批准的时间源
2
w32tm /config /manualpeerlist:"ntp1.example.net,0x8 ntp2.example.net,0x8" /syncfromflags:manual /reliable:yes /update
3
Restart-Service w32time
4
w32tm /resync /rediscover

1
# 非 PDC 的 DC 恢复为域层级同步
2
w32tm /config /syncfromflags:domhier /update
3
Restart-Service w32time
4
w32tm /resync /rediscover
5

6
# 验证并重新发现时间源
7
w32tm /query /source
8
w32tm /resync /rediscover

1
w32tm /monitor /domain:qy.net       # 偏差回到毫秒级
2
repadmin /replsummary                     # 复制是否也恢复正常
3
Get-Service W32Time                       # 确认 Automatic + Running

1
# 工作日志：AD 域控时间同步故障排查与修复
2

3
日期：YYYY-MM-DD
4
执行人：
5
环境：测试域 contoso.com（DC01=PDC/GC，DC02=DC/GC，成员服务器 fs01/app01）
6
关联 Topic：AD 每日研究 #1 域控时间同步源梳理与修复
7

8
## 一、问题现象
9
- [填写：谁、什么时候、反馈什么现象，例如"09:12 起多个系统 Kerberos 认证偶发失败"]
10
- [填写：事件日志关键条目与 Event ID]
11

12
## 二、排查过程
13
1. 现象分类：先区分是"凭据问题"还是"环境问题"，[填写判断依据]
14
2. 时间层检查：执行 `w32tm /monitor /domain:contoso.com`，结果：
15
   - DC01 偏移：___ 秒
16
   - DC02 偏移：___ 秒
17
3. 定位 PDC 与时间源：`netdom query fsmo` → PDC 为 ___；
18
   `w32tm /query /status /verbose` → Source 为 ___，Stratum ___，
19
   Last Successful Sync Time ___
20
4. 发现异常配置：[例如 DC02 被改为 manual peer，或 PDC 指向不可达源]
21
5. 排除项：DNS 解析正常、网络连通正常、账号密码验证正常（已验证，非根因）
22

23
## 三、根因
24
[填写：一句话说明，例如"DC01 上 PDC Emulator 的外部时间源配置丢失且被手动改表，
25
导致域内时间层级失效，Kerberos 因超过 5 分钟容差而拒绝认证"]
26

27
## 四、修复动作
28
1. 在 DC01(PDC) 上重新配置外部 NTP 源并标记 reliable：`w32tm /config ...`
29
2. 在 DC02 等 DC 上恢复 `NT5DS` 域层级：`w32tm /config /syncfromflags:domhier /update`
30
3. 全量重新同步：`w32tm /resync /rediscover` + 重启 W32Time
31
4. 关闭虚拟化平台与 w32time 冲突的主机时间同步（VMware Tools Time Sync）
32
5. 核对 GPO 时间相关策略，防止被覆盖
33

34
## 五、验证结果
35
- `w32tm /monitor`：各 DC 偏差收敛至 ___ ms
36
- Kerberos 认证：复测业务系统登录 ___ 次，成功 ___ 次
37
- `repadmin /replsummary`：无失败项
38
- W32Time 服务状态：Running / Automatic（全部 DC）
39

40
## 六、复盘与改进
41
- 教训：[例如"认证类故障应第一时间排查时间层，而非凭据"]
42
- 待办：
43
  - [ ] 将时间健康检查加入日常巡检（每日/每周自动采集 `w32tm /monitor`）
44
  - [ ] 通过 GPO 固化时间源配置，禁止手工改表
45
  - [ ] 关闭所有虚拟化域控的宿主时间同步
46
  - [ ] 补充监控告警：DC 时间偏移 > 阈值 触发告警
47

48
## 七、耗时统计
49
- 排查：___ 分钟
50
- 修复：___ 分钟
51
- 验证与收尾：___ 分钟
52
- 合计：___ 分钟

二、全局编录(GC)覆盖审计与站点复制拓扑核查#

检查每台 DC 是否承担 GC，确认站点间是否仍有可用复制路径，并结合 repadmin /replsummary 生成健康报告。

量化：找出复制失败的 DC 对，修复并复测。

GC：Global Catalog，中文叫全局编录。它算是一个角色，但更准确地说，它是 DC 承担的一种功能角色——不是所有 DC 都必须承担，但承担了的 DC 就叫 GC 服务器。

为了核查 GC 的状态，把它分成三步：检查、诊断、修复。

1
# 简易列出 GC
2
Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalog
3

4
# 详细列出 GC
5
Get-ADDomainController -Filter * | Where-Object {$_.IsGlobalCatalog -eq $true}
6

7
# 当然、dsquery 也可以
8
dsquery server -isgc

1
# 查看所有 DC 的入站复制状态
2
repadmin /showrepl *
3

4
# 查看指定 DC 的连接对象
5
repadmin /showconn <DC Name>
6

7
# 使用 PowerShell 查询站点、站点链接和连接对象
8
Get-ADReplicationSite -Filter *
9
Get-ADReplicationSiteLink -Filter *
10
Get-ADReplicationConnection -Filter *

1
# 这是核心命令，它会列出每台 DC 的最大复制偏差（delta）和失败计数，快速定位有问题的 DC
2
repadmin /replsummary
3

4
# 如果要更详细的 CSV 报告，使用管道导出即可
5
repadmin /showrepl * /csv > repl.csv
6

7
# 只看有错误的
8
repadmin /replsummary /errorsonly

1
repadmin /showrepl <DCName> /verbose

三、用户已经加入组，但仍然没有权限#

这是 AD 权限排查中的高频问题。不要只确认“用户是否在组里”，需要同时检查四层状态：

1. AD 成员关系：组是否为 Security、作用域是否正确、嵌套关系能否展开、变更是否已复制。
2. 登录令牌：用户当前令牌是否已经包含新组，必要时注销并重新登录。
3. 共享权限：SMB Share ACL 是否允许访问。
4. 文件系统权限：NTFS ACL 是否允许访问，是否存在优先级更高的显式拒绝。

1
Get-ADGroup -Identity "目标组" -Properties GroupCategory,GroupScope
2

3
Get-ADGroupMember -Identity "目标组" -Recursive
4

5
whoami /groups
6

7
# 查看客户端现有的票据和 SMB 连接
8
klist
9
net use
10

11
# 在文件服务器上查询共享 ACL
12
Get-SmbShareAccess -Name "ShareName"
13

14
# 查询目录的 NTFS ACL
15
Get-Acl "D:\Shares\ShareName" |
16
    Select-Object -ExpandProperty Access
17

18
repadmin /replsummary

Get-SmbSession 和 Get-SmbOpenFile 查询的是会话与打开文件，不是共享 ACL。gpupdate /force 和 klist purge 都不会重新生成用户的桌面登录令牌。用户在登录后才被加入组时，最可靠的验证方法仍然是注销并重新登录；旧 SMB 连接还应在关闭文件后重新建立。

四、AD 复制错误 1722：RPC 服务器不可用#

错误 1722 表示 RPC 通信无法建立，不等于目标 DC 一定关机。推荐沿着以下顺序排查：

1
DNS 解析
2
    ↓
3
基础网络与路由
4
    ↓
5
TCP 135（RPC Endpoint Mapper）
6
    ↓
7
RPC 动态端口与防火墙
8
    ↓
9
NTDS、RPC、Netlogon 等服务
10
    ↓
11
DCDiag、Repadmin 与事件日志

1
Resolve-DnsName QYNET-CORE02.qy.net
2
Test-NetConnection QYNET-CORE02 -Port 135
3
Test-NetConnection QYNET-CORE02 -Port 389
4
Test-NetConnection QYNET-CORE02 -Port 445
5

6
Get-Service -ComputerName QYNET-CORE02 `
7
    -Name RpcSs,RpcEptMapper,Netlogon,NTDS,KDC,DNS
8

9
dcdiag /s:QYNET-CORE02 /test:Connectivity /v
10
dcdiag /s:QYNET-CORE02 /test:DNS /DnsBasic /v
11
dcdiag /s:QYNET-CORE02 /test:Replications /v
12
repadmin /showrepl QYNET-CORE02 /verbose

Ping 使用 ICMP，不存在“Ping 端口”。Ping 失败可能只是 ICMP 被阻止；Ping 成功也不能证明 TCP 135 和协商出的 RPC 动态端口可用。完成修复后必须重新执行 repadmin /replsummary 和 /showrepl，并核对 System、Directory Service、DNS Server 与 DFS Replication 日志。

五、计算机能够登录域，但没有应用预期 GPO#

能够使用域账户登录，只能证明至少有一台 DC 完成了认证，不能证明计算机位于正确 OU、GPO 链接有效、SYSVOL 可访问或策略处理成功。

推荐检查链：

1
计算机对象与 OU
2
    ↓
3
GPO 链接、继承和安全筛选
4
    ↓
5
客户端 DNS 与 DC Locator
6
    ↓
7
DC Advertising、复制与 SYSVOL
8
    ↓
9
gpupdate 与 gpresult

1
Get-ADComputer -Identity PC-LAB-01 |
2
    Select-Object Name,DistinguishedName
3

4
Get-GPInheritance -Target "OU=Lab,OU=Computer,OU=Organization,DC=qy,DC=net"
5

6
nltest /dsgetdc:qy.net
7
Test-Path "\\qy.net\SYSVOL"
8
Test-Path "\\qy.net\NETLOGON"
9

10
gpupdate /force
11
gpresult /Scope Computer /R
12
gpresult /Scope Computer /H "C:\Temp\Computer-GPO.html"

Day1 的完整答题与批改过程见：Windows AD Practice Day1。

六、服务从 Kerberos 回退到 NTLM#

业务能够打开不代表正在使用 Kerberos。应用可能因为 SPN 缺失、重复、绑定错误、访问名称不匹配或客户端配置而回退到 NTLM。

推荐检查链：

1
访问名称与 DNS
2
    ↓
3
KDC 与 Kerberos SRV
4
    ↓
5
主动请求目标服务票据
6
    ↓
7
SPN 唯一所有者
8
    ↓
9
服务实际运行身份
10
    ↓
11
客户端票据与 KDC 事件
12
    ↓
13
修复后重新认证并验证协议

1
Resolve-DnsName testweb.qy.net
2
Resolve-DnsName -Type SRV "_kerberos._tcp.qy.net"
3
nltest /dsgetdc:qy.net /KDC /force
4

5
klist get HTTP/testweb.qy.net
6

7
setspn -F -Q HTTP/testweb.qy.net
8
setspn -X -F
9
setspn -L QY\svc_testweb
10

11
w32tm /query /status
12
klist

修复后，应同时确认客户端出现目标服务票据、DC 记录成功的 4769、对应访问不再持续产生 4776，并且 SPN 属于服务实际使用的账户。klist get 成功只证明 KDC 能签发票据，不能单独证明服务端可以解密、应用已经使用票据或 ACL 已授权。

Day2 的完整答题与批改过程见：Windows AD Practice Day2。

课题一：域安全基线 GPO 差异审计#

对照 Microsoft Security Baselines 或组织采用的安全基线，导出当前域 GPO 设置并生成差异清单，逐项评估兼容性与加固收益。

验收标准：输出差异项数量、建议加固点、例外项及回退方案。

课题二：RODC 或新增、下架域控的全流程演练#

在实验环境演练提升新 DC、验证 DNS 与 GC、转移必要角色、安全降级旧 DC，以及异常降级后的元数据清理。

验收标准：形成提升、验证、降级、元数据清理和回退检查清单，并保留关键命令结果。

课题三：废弃账号与特权账号治理#

结合最后登录、密码修改、账户状态、组成员关系和资产负责人确认，识别长期闲置账号以及 DA、EA、BA 等高权限组中的非必要成员。

验收标准：记录候选账号、人工复核结果、禁用观察期、最终处置和特权组收敛数量。

课题四：受控灾难恢复演练#

选择“AD 回收站还原误删对象”或“系统状态备份恢复域控”进行受控演练，明确权威与非权威恢复边界。

验收标准：记录 RTO、RPO、恢复步骤、验证项、失败点和完整演练报告。

课题五：Kerberos 与 NTLM 使用情况观测#

基于高级审核日志统计 Kerberos TGT、服务票据及 NTLM 凭据验证事件，识别仍依赖 NTLM 的客户端、服务和访问路径。

验收标准：统计认证协议占比，列出 NTLM 来源、业务负责人、迁移难点和可执行的收紧计划。

课题六：DNS 记录清理与条件转发健康检查#

检查条件转发器、存根区域、SRV、CNAME、A 与 PTR 记录，识别陈旧或冲突记录；所有删除操作必须先生成候选报告并确认业务归属。

验收标准：记录清理候选、审批结果、实际清理数量、转发延迟和清理后的客户端解析验证。

课题七：细粒度密码策略（PSO）#

在确认域功能级别和业务需求后，为高权限人员、服务账户和普通用户设计不同的密码与锁定策略，并验证 Resultant PSO。

验收标准：保留改造前后配置、优先级设计、目标用户、冲突处理和生效验证样例。

课题八：域与林信任关系安全审计#

梳理信任方向、传递性、身份验证范围、SID History 与 SID Filtering 等配置，评估攻击者利用信任关系横向移动的风险。

验收标准：形成信任清单、风险项、业务依赖、整改建议和验证方法。

每日训练入口：Day1 · Day2