今天的总体评价#

主卷共 12 题，后面还有对话加练。概念方向掌握度约为 55%～60%：能够较快判断问题属于组权限、RPC、SPN、Kerberos 或时间层面，但命令精度、概念边界和完整验证链仍需加强。部分“我的回答”为当时作答摘要，而非逐字转录。

本日重点错题：Q2、Q3、Q4、Q9、Q10、Q11、Q12。

Q1：组对象、组成员与用户所属组#

**题目：**分别查询 QYNET-Admin 组对象、递归成员，以及 qianyue 所属的组。

我的回答：

1
Get-ADGroup QYNET-Admin
2

3
Get-ADGroupMember -Identity QYNET-Admin -Recursive
4

5
Get-ADPrincipalGroupMembership -Identity qianyue

批改：

回答正确。Get-ADGroup 的第一个位置参数就是 -Identity，因此第一条省略参数名仍然有效。

三条命令分别查询：

若要检查组能否用于授权，应继续查看类别和作用域：

1
Get-ADGroup -Identity QYNET-Admin |
2
    Select-Object Name,GroupCategory,GroupScope

Q2：三种最后登录时间#

**题目：**解释 LastLogonDate、lastLogonTimestamp 与 lastLogon 的来源、复制特性和用途；如何较准确地查询最后登录时间？

我的回答：

• LastLogonDate 是最后登录日期。
• LastLogonTimeStamp 是最后登录时间戳。
• LastLogon 是最后登录时间。
• LastLogon 最精确；查询所有 DC 是因为复制可能滞后，尤其要关注 PDC。

批改：需要纠正的地方

前半部分只是根据名称解释，没有说明真正的技术区别。查询所有 DC 也不是为了等待复制完成，而是因为 LastLogon 根本不会在 DC 之间复制；PDC 并不保存全域唯一、最完整的 LastLogon。

正确思路与答案：

1
# 粗筛 90 天未登录用户
2
Search-ADAccount `
3
    -AccountInactive `
4
    -TimeSpan 90.00:00:00 `
5
    -UsersOnly

查询一个用户在所有 DC 上的 LastLogon：

1
$user = "qianyue"
2

3
Get-ADDomainController -Filter * |
4
    ForEach-Object {
5
        $result = Get-ADUser `
6
            -Identity $user `
7
            -Server $_.HostName `
8
            -Properties LastLogon
9

10
        [pscustomobject]@{
11
            DomainController = $_.HostName
12
            LastLogon = if ($result.LastLogon -gt 0) {
13
                [datetime]::FromFileTime($result.LastLogon)
14
            }
15
        }
16
    } |
17
    Sort-Object LastLogon -Descending

重点复习：LastLogonDate 不是一套更粗的独立登录记录，它只是 lastLogonTimestamp 的易读转换。

Q3：已经加入安全组，为什么仍然没有共享权限#

题目：qianyue 已加入 QYNET-File-Read，却仍无法访问共享。如何区分 AD 成员关系、当前令牌、票据、SMB 会话、共享 ACL 与 NTFS ACL？

我的回答：

当时写了：

1
Get-ADGroupMember -Identity QYNET-File-Read -Recursive
2
Get-ADPrincipalGroupMembership -Identity qianyue
3

4
whoami /all
5
whoami /groups
6

7
net use
8
klist
9

10
Get-SmbSession
11
Get-SmbOpenFile

批改：做得好的地方

• 知道同时检查 AD 组成员关系和客户端登录令牌。
• 知道旧的 SMB 连接和 Kerberos 票据可能继续保存原身份状态。
• 知道问题不能只在 DC 上检查。

正确思路与答案：关键遗漏

Get-SmbSession 和 Get-SmbOpenFile 查询的是服务器上的 SMB 会话与打开文件，不是共享 ACL。

共享权限应在文件服务器上查询：

1
Get-SmbShareAccess -Name "Public"

NTFS ACL 应查询共享对应的本地目录：

1
Get-Acl "D:\Shares\Public" |
2
    Select-Object -ExpandProperty Access

完整排查链：

1
# 1. AD 成员关系与组类型
2
Get-ADGroup -Identity QYNET-File-Read |
3
    Select-Object Name,GroupCategory,GroupScope
4

5
Get-ADGroupMember -Identity QYNET-File-Read -Recursive |
6
    Where-Object SamAccountName -eq "qianyue"
7

8
# 2. 当前登录令牌
9
whoami /groups | findstr /i "QYNET-File-Read"
10

11
# 3. 当前票据与旧连接
12
klist
13
net use
14

15
# 4. 在文件服务器上查询共享与 NTFS ACL
16
Get-SmbShareAccess -Name "Public"
17

18
Get-Acl "D:\Shares\Public" |
19
    Select-Object -ExpandProperty Access

判断刷新方式：

• SPN、服务账户或旧服务票据变化：修复根因后可以使用 klist purge 验证。
• 用户登录后才被加入新组：klist purge 不会重建当前桌面登录令牌，最可靠的方法是注销并重新登录。
• 已建立 SMB 连接：关闭文件后使用 net use \\server\share /delete，再重新连接。

重点复习：SMB 会话不是共享权限；共享 ACL 和 NTFS ACL 必须分别检查。

Q4：复制错误 1722#

**题目：**某 DC 复制错误 1722。如何解释 Ping、TCP 135 的测试结果，并按顺序检查 DNS、RPC、服务与复制详情？

我的回答：

当时提到了 Ping、名称解析、RpcEptMapper、TCP 135 和防火墙，并指出 Ping 失败不等于服务器关机。

批改：需要修正的地方

1. Ping 使用 ICMP，不存在“Ping 的端口”。
2. TCP 135 只负责 RPC Endpoint Mapper；实际 RPC 会话还会使用协商出的动态 TCP 端口。
3. Get-NetFirewallRule -DisplayName "RPC" 是精确名称匹配，通常不能完整列出 RPC 相关规则。
4. 动态 RPC 不是简单查一个名为 Dynamic 的防火墙规则。
5. 缺少 repadmin /showrepl、DCDiag 和事件日志。

正确思路与答案：推荐顺序

1
# 1. 名称与地址
2
Resolve-DnsName QYNET-CORE02.qy.net
3
Resolve-DnsName 192.168.254.11 -Type PTR
4
nltest /dsgetdc:qy.net /force
5

6
# 2. ICMP 只作参考
7
Test-Connection QYNET-CORE02 -Count 2
8

9
# 3. 常见 AD 端口与 RPC Endpoint Mapper
10
Test-NetConnection QYNET-CORE02 -Port 53
11
Test-NetConnection QYNET-CORE02 -Port 88
12
Test-NetConnection QYNET-CORE02 -Port 135
13
Test-NetConnection QYNET-CORE02 -Port 389
14
Test-NetConnection QYNET-CORE02 -Port 445
15

16
# 4. 检查关键服务
17
Get-Service -ComputerName QYNET-CORE02 `
18
    -Name RpcSs,RpcEptMapper,Netlogon,NTDS,KDC,DNS
19

20
# 5. 查看目标 DC 的入站复制详情
21
repadmin /showrepl QYNET-CORE02 /verbose
22

23
# 6. 验证连通性、DNS 和复制
24
dcdiag /s:QYNET-CORE02 /test:connectivity /v
25
dcdiag /s:QYNET-CORE02 /test:DNS /v
26
dcdiag /s:QYNET-CORE02 /test:replications /v
27

28
# 7. 修复后重新验证
29
repadmin /replsummary
30
repadmin /showrepl QYNET-CORE02

RPC 动态端口在现代 Windows Server 上通常位于高位 TCP 端口范围。TCP 135 成功只表示能联系 Endpoint Mapper，不能证明后续协商的动态端口一定畅通。

还应检查目标 DC 的 System、Directory Service、DNS Server 和 DFS Replication 日志。

重点复习：1722 是 RPC 通信链失败，不是“服务器关机”的同义词。

Q5：DNS、SRV 与 SPN#

**题目：**查询 Kerberos SRV 记录、全林 SPN 所有者与重复项，并为服务账户安全添加 SPN。

我的回答：

当时记得 setspn -Q、setspn -X 和 setspn -S 的主要作用；SRV 查询名称与全林范围没有写完整。

批改： SRV 名称未写完整，也漏了全林查询范围；setspn -Q、-X、-S 的方向已掌握。正确命令如下：

1
# 1. 查询 Kerberos KDC SRV 记录
2
Resolve-DnsName -Type SRV "_kerberos._tcp.qy.net"
3

4
# 也可以使用 Nslookup
5
nslookup -type=SRV _kerberos._tcp.qy.net
6

7
# 2. 在整个林中反向查询 SPN 所有者
8
setspn -F -Q HTTP/testweb.qy.net
9

10
# 3. 在整个林中检查重复 SPN
11
setspn -X -F
12

13
# 4. 安全添加 SPN
14
setspn -S HTTP/testweb.qy.net QY\svc_testweb

setspn -U 用来明确目标是用户账户，在已提供明确域用户名称时通常不是必需项。

-S 会先检查重复再添加；-A 直接写入，可能制造重复 SPN。重复 SPN 会使 KDC 无法唯一确定应该使用哪个账户密钥，导致票据申请失败或认证异常。

重点复习：SRV 查询必须包含服务和协议标签，例如 _kerberos._tcp.qy.net，不能只查询普通域名。

Q6：Kerberos 认证流程#

**题目：**按顺序说明 TGT、KDC、TGS、SPN、服务票据和目标资源 ACL 在 Kerberos 访问中的作用。

我的回答：

当时描述的大致顺序是：KDC 验证用户、TGT 用于继续申请票据、TGS 签发服务票据、SPN 标识目标服务。

批改：需要修正的地方

• KDC 不是“服务票据本身”，而是运行在 DC 上的密钥分发服务。
• SPN 不只是资源名称，而是把服务实例映射到 AD 安全主体。
• 目标服务账户密钥不是交给用户的“访问钥匙”，而是服务端用于解密和验证服务票据的密钥。

正确思路与答案：完整流程

1
1. 用户登录，客户端向 KDC 的 AS 请求 TGT
2
                    ↓
3
2. AS 验证用户，返回 TGT
4
                    ↓
5
3. 客户端携带 TGT，并以目标 SPN 请求服务票据
6
                    ↓
7
4. KDC 的 TGS 查找 SPN 所属账户，签发服务票据
8
                    ↓
9
5. 客户端把服务票据交给目标服务
10
                    ↓
11
6. 目标服务使用自身账户密钥解密并验证票据
12
                    ↓
13
7. 服务根据用户身份、组信息与资源 ACL 决定是否授权

拿到 TGT 只证明用户可以继续向 KDC 申请服务票据。它不证明：

• 目标 SPN 存在且属于正确账户。
• 目标服务能够解密票据。
• 服务在线并接受 Kerberos。
• 共享权限和 NTFS ACL 已授权。

Q7：阅读 klist 结果#

**题目：**阅读 klist 输出：缓存为空说明什么？krbtgt 与 cifs 票据有何区别？klist get 成功能证明什么？

**我的回答：**新登录会话尚未使用 Kerberos 访问服务时，票据缓存可以为空；第二问用“服务端票据、客户端票据”区分两张票据。

**批改：**第一问正确；第二问应区分 TGT 与目标服务票据，而不是“服务端/客户端票据”：

klist get 成功可以证明：

1. 当前登录会话能够联系 KDC。
2. 当前主体能够获得 TGT。
3. KDC 能够把目标 SPN 唯一解析到一个主体并签发服务票据。
4. 票据已经进入当前登录会话缓存。

它不能证明：

1. SPN 一定注册在实际运行服务的正确账户上。
2. 目标服务拥有匹配密钥并能解密票据。
3. 应用实际使用了这张票据，而不是回退到 NTLM。
4. 服务在线、业务正常或 ACL 已允许访问。

如果 KDC 能看到重复 SPN，通常会因为主体不唯一而拒绝签发；因此“成功签发后仍完全不能说明是否重复”不够准确。但 DC 复制不一致时，仍应结合 setspn -X -F 检查全林状态。

Q8：klist purge 的边界#

**题目：**用户刚加入安全组却仍无权限，klist purge 能刷新什么、不能刷新什么？应如何验证与重新登录？

我的回答：

它清的是 Kerberos 票据，不是登录令牌。必须注销，或者创建新的登录会话。

批改：

核心判断正确，但处理流程还应补全：

1. 先确认 AD 中的新组成员关系已存在并已复制。
2. 使用 whoami /groups 检查当前登录令牌。
3. 如果令牌缺少新组，注销并重新登录。
4. 关闭已打开文件，再清理旧 SMB 连接。
5. 修复 SPN 或服务身份后，才使用 klist purge 排除旧票据。
6. 重新连接资源并检查新票据和权限。

1
whoami /groups
2
klist
3
net use
4

5
net use \\QYNET-FS01\Public /delete
6
klist purge

klist purge 不会重建当前桌面会话的本地访问令牌，也不会自动保证所有应用重新建立连接。

Q9：票据属于哪一个会话#

**题目：**解释 klist 的票据属于哪个登录会话、0x3e7 和 LUID 的含义，并区分 LUID、SID 与 ObjectGUID。

我的回答：

• 认为 0x3e7 通常是 SYSTEM 登录会话。
• 认为票据缓存按登录会话隔离。
• 对 LUID 与 SID、GUID 的区别不确定。

**批改：**知道票据缓存按会话隔离，也认出了 SYSTEM 常见的 0x3e7；需要把 LUID 与 SID、ObjectGUID 分开。

正确思路与答案：

klist sessions 用于列出本机登录会话，包括每个会话的 LUID、账户和认证类型。

LUID 是由本机 LSA 分配的 Locally Unique Identifier，用于在当前计算机、当前运行周期中标识一个登录会话。它不是：

• 用户或组的 SID。
• AD 对象的 ObjectGUID。
• 全域或全林身份标识。

1
# 当前命令所在登录会话
2
klist
3

4
# 列出所有登录会话
5
klist sessions
6

7
# 查询 SYSTEM 会话
8
klist -li 0x3e7

普通 klist 只查看当前命令所属 LUID 的缓存。Windows 服务、SYSTEM、计划任务、远程管理和其他用户分别处在不同登录会话中，因此不会自动显示在当前缓存里。

klist purge -li 0x3e7 会清除计算机身份和 SYSTEM 服务使用的票据，可能影响 GPO、LDAP、SMB、服务认证和其他域操作。在 DC 上尤其不应随意执行，但也不是“一执行 DC 就必然爆炸”；应准确描述为高影响操作。

重点复习：LUID 标识本机登录会话，SID 标识安全主体，ObjectGUID 标识 AD 对象。

Q10：AD 域时间层级#

**题目：**说明 AD 域时间层级：哪个 PDC 应对接权威上游，其他 DC 与成员机通常如何同步？

我的回答：

当时提到了 PDC 与外部 NTP、其他 DC 和客户端之间的层级，也指出让所有成员机访问公网会增加安全和稳定性问题。

批改：两个关键错误

1. 不是每个域的 PDC Emulator 都直接配置公网 NTP；默认只让林根域 PDC Emulator位于整林时间层级顶端并对接权威上游。
2. 时间不是由 PDC 通过 GPO“下发”到其他计算机；GPO 可以配置 W32Time，但实际同步由 Windows Time 服务按照域层级和选择算法完成。

1
权威外部 NTP / 组织内部时钟
2
                ↓
3
林根域 PDC Emulator
4
                ↓
5
子域 PDC Emulator与其他合适的上级 DC
6
                ↓
7
其他域控制器
8
                ↓
9
成员服务器与客户端

普通成员默认使用 NT5DS，从域层级选择时间源。这样可以：

• 保持全林时间一致。
• 使用域内经过身份验证的时间同步。
• 避免每台设备依赖公网与外部 DNS。
• 避免形成混乱或循环的时间拓扑。

Q11：分析实验环境的时间状态#

**题目：**实验环境中的林根域 PDC 显示 Local CMOS Clock、Type: NT5DS 和 Stratum: 1。这些结果分别能、不能证明什么？配置前应检查什么？

我的回答：

当时识别出 Local CMOS Clock 与林根域 PDC，并提到配置前要检查 UDP 123、DNS 和已有配置。

批改：需要修正的地方

Type: NT5DS 不表示“NT5DS 的来源是本地 CMOS”。它表示 W32Time 正尝试从 AD 域层级选取时间源；由于该服务器本身就是林根域 PDC，层级上方没有其他域时间源，最终退回到本地硬件时钟。

Stratum: 1 也不能单独证明连接了外部硬件时钟。本机以 LOCL 作为 RefID 时，也可能把自己作为低层级时间源播发。应同时检查：

• Source
• ReferenceId / RefID
• Last Successful Sync Time
• /query /peers
• Time-Service 事件日志

正确思路：配置前检查

1
Get-ADDomain | Select-Object DNSRoot,PDCEmulator
2
Get-ADForest | Select-Object RootDomain
3

4
w32tm /query /source
5
w32tm /query /status
6
w32tm /query /configuration
7
w32tm /query /peers
8

9
Resolve-DnsName ntp.aliyun.com
10
w32tm /stripchart /computer:ntp.aliyun.com /samples:5 /dataonly

当前实验 VM 无法解析 ntp.aliyun.com，所以正式配置前还需要先修复外部 DNS 解析，或使用组织内部可解析的权威时间源。

示例命令：

以下命令只作复习，本次训练没有在 VM 上执行：

1
w32tm /config `
2
    /syncfromflags:manual `
3
    /manualpeerlist:"ntp.aliyun.com,0x8" `
4
    /reliable:yes `
5
    /update
6

7
Restart-Service W32Time
8

9
w32tm /resync /rediscover
10

11
w32tm /query /source
12
w32tm /query /status
13
w32tm /query /peers
14
w32tm /query /configuration

原回答中分两行执行 net stop w32time 与 net start w32time 也能工作；在 PowerShell 笔记中使用 Restart-Service W32Time 更直观。还遗漏了重新同步与 /peers、/configuration 验证。

Q12：Web 服务从 Kerberos 回退到 NTLM#

**题目：**Web 服务从 Kerberos 回退到 NTLM。如何核对 DNS/KDC、SPN、服务身份、票据、时间、事件日志，并形成复测闭环？

我的回答：

当时提出 SPN 缺失、绑错账户或重复，以及浏览器配置和时间偏差等方向；写了三条检查命令。

**批改：**SPN、浏览器配置和时间偏差等方向正确，但原答只覆盖了部分检查命令，尚缺少从客户端到服务端的验证闭环。下面是完整排查链。

1
Resolve-DnsName testweb.qy.net
2

3
Resolve-DnsName -Type SRV "_kerberos._tcp.qy.net"
4

5
nltest /dsgetdc:qy.net /KDC /force

1
klist get HTTP/testweb.qy.net

1
setspn -F -Q HTTP/testweb.qy.net
2
setspn -X -F
3
setspn -L QY\svc_testweb

1
Invoke-Command -ComputerName TESTWEB -ScriptBlock {
2
    Import-Module WebAdministration
3

4
    Get-ChildItem IIS:\AppPools |
5
        Select-Object Name,
6
            @{Name="IdentityType";Expression={$_.processModel.identityType}},
7
            @{Name="UserName";Expression={$_.processModel.userName}}
8
}

1
w32tm /query /source
2
w32tm /query /status
3

4
klist

1
klist purge

1
$startTime = (Get-Date).AddMinutes(-30)
2

3
Get-WinEvent -FilterHashtable @{
4
    LogName   = "Security"
5
    Id        = 4768,4769,4771,4776
6
    StartTime = $startTime
7
} |
8
    Where-Object Message -Match "qianyue|svc_testweb|HTTP/testweb.qy.net" |
9
    Select-Object TimeCreated,Id,Message

1
klist | findstr /i "HTTP/testweb.qy.net"
2

3
klist get HTTP/testweb.qy.net

重点订正：四类共性问题#

闭卷追练：从命令记忆到排障判断#

随后在聊天中连续练习了命令和故障判断。以下记录的是当时的作答与纠正，不是在 VM 上重新执行后的输出。常用命令已经能较快写出；剩下的主要问题是属性拼写、查询范围，以及把不同层面的状态混为一谈。

1
Get-ADUser -Filter 'Enabled -eq $true -and Department -eq "IT"' `
2
    -Properties Department |
3
    Select-Object Name, SamAccountName, Department

1
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
2
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

1
AD 组成员关系 → 当前登录令牌（whoami /groups）
2
               → 共享权限（Get-SmbShareAccess）
3
               → NTFS ACL（Get-Acl）

1
repadmin /syncall /AdeP

1
$newUserSam = "newuser"  # 改成刚创建的用户登录名
2

3
Get-ADUser -Identity $newUserSam -Server DC01
4
Get-ADUser -Identity $newUserSam -Server DC02
5

6
repadmin /showrepl DC02

1
# 目标 DC 在前，源 DC 在后
2
repadmin /replicate DC02 DC01 "DC=qy,DC=net"

下次开场先闭卷复述的十三句话#

不看答案，尝试口述下面十三句话：

1. LastLogonDate 是 lastLogonTimestamp 的易读转换。
2. LastLogon 不复制，所以精确查询要遍历所有 DC 并取最大值。
3. Get-SmbSession 不是共享 ACL；共享 ACL 使用 Get-SmbShareAccess。
4. Ping 使用 ICMP，没有所谓“Ping 端口”。
5. LUID 标识本机登录会话，不是 SID 或 ObjectGUID。
6. klist get 成功不证明服务能解密票据或 ACL 已授权。
7. 默认只有林根域 PDC Emulator 对接外部权威时间源。
8. Kerberos 回退要检查 DNS、KDC、SPN、服务身份、票据与事件日志。
9. -Filter 找对象，-Properties 取额外字段，Select-Object 控制输出。
10. 刚加组却无权限：先查登录令牌，再查共享权限与 NTFS ACL。
11. 1722：DNS → 网络 → RPC 135 → 动态 RPC 端口与服务。
12. AGDLP：用户 → Global → DomainLocal → 资源权限。
13. 多站点复制先选最小范围；/e 跨站点、/P 推送，不要无差别使用 /syncall /AdeP。

重要问题库：Windows AD 重要问题库

上一篇：Windows AD Practice Day1

下一篇：Windows AD Practice Day3