今天的总体评价#

这次 50 分钟答完 12 题，Q1、Q3、Q6 答得完整；Q4、Q8、Q9 基本正确；Q5、Q7、Q10、Q12 有关键步骤缺漏；Q11 尚未形成完整闭环。Q2 的账户/计算机命令写反，学习者说明是看错题，按审题笔误记录，不计作“不会计算机账户”。这不是考试分数，而是下次出题的定位依据。

Q1：用户筛选：三种参数各管什么（闭卷）#

题目：

找出已启用且 Department 为 IT 的用户，只显示 Name、SamAccountName、Department。写出一条完整命令，并用一句话区分 -Filter、-Properties 与 Select-Object。

我的回答：

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

一句话区分，一个是筛选，一个是附加属性，一个是select选择print输出的属性

批改：完整。 原命令正确。“select 选择 print 输出”表达也能说明意思，不过更准确地说：Select-Object 从已取回的对象中选出要显示的属性，不会替你重新向 AD 查询。

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

Q2：计算机账户：查找与退域（闭卷）#

题目：

1. 找出所有已禁用的计算机账户，只显示 Name、DNSHostName、DistinguishedName。
2. Remove-ADComputer 与 Remove-Computer 分别改变什么？哪一个才会让 Windows 设备退出域？

我的回答：

1
Get-ADUser -Filter 'Enabled -eq $false' -Properties DNSHostName | Select-Object Name,DnsHostName,DistinguishedName

一个是删除计算机账户（Remove-ADComputer），一个是让计算机退出域（Remove-Computer）。

批改：审题笔误。 原答把题目里的“计算机”看成了“用户”，因此写了 Get-ADUser。这条命令不能满足题意；但你对 Remove-ADComputer 与 Remove-Computer 的区分完全正确，不作为概念性错题。下次先圈出“查哪种对象”，再选 Get-ADUser / Get-ADComputer。

1
Get-ADComputer -Filter 'Enabled -eq $false' |
2
    Select-Object Name,DNSHostName,DistinguishedName

DNSHostName 在这里不必额外通过 -Properties 获取；Remove-Computer 是让 Windows 设备退出域，Remove-ADComputer 只是删除 AD 中的计算机对象。

Q3：组的方向与授权（闭卷）#

题目：

qianyue 被加入 QYNET-Admin。分别写命令：

1. 查 qianyue 属于哪些组。
2. 查 QYNET-Admin 的成员，展开嵌套组。
3. 查 QYNET-Admin 是安全组还是通讯组，以及它的作用域。

最后用“用户 → 组 → 组 → 文件夹 ACL”的形式，写出 AGDLP 的授权链，并说明哪个组类型才能用于 ACL。

我的回答：

1. Get-ADPrincipalGroupMembership -Identity 'qianyue'
2. Get-ADGroupMember -Identity 'QYNET-Admin' -Recursive
3. Get-ADGroup -Identity 'QYNET-Admin' QYNET-Admin 为 安全组，作用域为 Global。 AGDLP：qianyue -> QYNET-Admin -> QYNET-File-Read（Domain Local） -> ACL 应该是安全组（Security）类型作用于 ACL。

批改：完整。 三种查询命令、Security/Global 的判断和“用户 → Global → Domain Local → ACL”链条都对。Get-ADGroup -Identity 'QYNET-Admin' 默认能看到 GroupCategory、GroupScope；若只显示要求的字段，可写：

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

Q4：最后登录时间（闭卷）#

题目：

管理员要筛出90 天未登录的计算机，另有一台关键机器需要尽量准确地查最后登录时间。你分别选 LastLogonDate、lastLogonTimestamp 还是 lastLogon？是否只查 PDC 就够？说明原因；不必写完整脚本。

我的回答：

粗筛：LastLogonDate 细筛：lastLogon

如果需要更加可靠的最后登录日期，最好多查几台DC，并不是只查PDC，确保数据的准确性。

批改：基本正确。 粗筛 LastLogonDate、较精确地查 lastLogon、不只看 PDC，这三点都想到了。精度要求高时，应该明确：查询该域的每台 DC 并取最大值；不是挑“几台”代表。原因是 lastLogon 不复制；lastLogonTimestamp 会复制，但更新不实时，所以适合长期不活跃的粗筛。微软对不复制属性的说明。

Q5：FSMO 与 GC（可翻笔记）#

题目：

不用 netdom query fsmo，写出两条 PowerShell 命令，分别显示林级两个和域级三个 FSMO 角色的持有者。另有一台 DC 显示 IsGlobalCatalog=False：这一定是故障吗？为什么？

我的回答：

Get-ADForest 查 结构主机与域命名 Get-ADDomain 查 RID、PDC、基础结构

False并非故障，它意味着不是全局编录服务器（GC）

批改：部分正确。 角色分类与 IsGlobalCatalog=False 的含义正确，但题目要求的“两条命令”没有写完。完整答案：

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

非 GC 仍可作为 DC 服务所在域，False 本身不等于故障。

Q6：时间、SPN 与 Kerberos（闭卷）#

题目：

USER01 比 DC01 快 10 分钟，访问域服务时认证失败。写出查看时间源和同步状态的两条命令。此时应优先怀疑时钟偏差还是SPN 重复？4771 的失败代码 0x25 能提供什么线索？

我的回答：

时钟偏差。

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

4771的0x25就是意味着时间偏差过大。

批改：完整。 10 分钟偏差应先查时间，两条 w32tm 命令都对；4771 的 0x25 也是时钟偏差过大的线索。这里没有必要在尚无 SPN 证据时优先查重复 SPN。微软的 4771 失败代码说明。

Q7：复制错误 1722（可翻笔记）#

题目：

repadmin /showrepl QYNET-CORE02 显示复制失败，错误码 1722；但从 CORE02 Ping CORE01 成功。请按先后顺序列出至少四项检查，并写出一条测试 TCP 135 的命令。为什么 Ping 成功仍不能证明复制正常？暂时不要执行强制全林复制。

我的回答：

ping 成功 意味着机器处于启动状态。

1. 查详细日志：repadmin /showrepl QYNET-CORE02 /verbose

2. 检查 DNS：dcdiag /s:QYNET-CORE02 /test:DNS /v

3. 检查相关服务：

   1
   Get-Service -ComputerName QYNET-CORE02 `
   2
       -Name RpcSs,RpcEptMapper,Netlogon,NTDS,KDC,DNS

4. 查 RPC 135：Test-NetConnection QYNET-CORE02 -Port 135

批改：部分正确。 repadmin /showrepl ... /verbose、DNS 测试与服务检查都值得做。Get-Service -ComputerName 在 Windows PowerShell 5.1 中可用；若换成 PowerShell 7，则应改用远程执行等方式。

这题的关键是：CORE02 是接收复制的目标，CORE01 是来源。要从 CORE02 测到 CORE01 的 TCP 135，而不是只测 CORE02 自己：

1
# 在 CORE02 上执行
2
Resolve-DnsName QYNET-CORE01.qy.net
3
Test-NetConnection QYNET-CORE01 -Port 135
4
repadmin /showrepl QYNET-CORE02 /verbose

Ping 成功仅表示 ICMP 对目标地址当时有响应，既不证明响应者一定是预期的 DC，也不证明 RPC Endpoint Mapper、动态 RPC 端口或 AD 复制正常。TCP 135 通也仍须检查协商后的动态端口与服务。微软 1722 排障说明。

Q8：DNS：配置与解析不是一回事（闭卷）#

题目：

USER01 加域时提示“找不到 qy.net”，但按 IP 可以 Ping 通 DC01。分别写命令：

1. 查看 USER01 配置了哪台 DNS 服务器。
2. 查询 qy.net 的 LDAP SRV 记录。
3. 只测试 qy.net 的名字能否被解析。

解释第 1 项与第 3 项为什么不能互相替代。

我的回答：

肯定是在 USER01 上跑的。

1. ipconfig /all
2. nslookup -type=srv _ldap._tcp.qy.net
3. Resolve-DnsName qy.net

一个只是查看本地的DNS服务器配置，一个是查看是否可以被正确解析（连通性，确认DNS服务器是否可用，因为可用才会被解析）

批改：基本正确。 ipconfig /all、nslookup -type=SRV _ldap._tcp.qy.net、Resolve-DnsName qy.net 分别满足三个小问。第 1 项也可用 Get-DnsClientServerAddress -AddressFamily IPv4。

要修正一句话：Resolve-DnsName 的一次成功，不足以证明“配置的那台 DNS 一定正确、可用且是 AD DNS”；可能有缓存、其他解析路径或备用服务器。要核对本机配置的服务器地址，还要针对指定 DNS 服务器查询 SRV 记录，不能只看域名能否解析。

Q9：SPN 查找与修改前验证（可翻笔记）#

题目：

某 Web 服务计划使用 HTTP/testweb.qy.net，运行账户为 svc_testweb。写出：

1. 在全林反查该 SPN 属于谁。
2. 在全林检查重复 SPN。
3. 确认服务确实运行于该账户后，安全添加 SPN 的命令。

为什么不推荐直接用 setspn -A？仅仅“没有重复”就能保证 Kerberos 正常吗？

我的回答：

1. setspn -F -Q HTTP/testweb.qy.net
2. setspn -F -X
3. setspn -S HTTP/testweb.qy.net svc_testweb -A 参数是直接添加，-S 是安全添加，如果出现重复则不添加。 仅仅没有重复是不能保证 Kerberos 服务正常的，影响它的因素还有很多。

批改：基本正确。 全林反查、全林查重、安全添加的命令都对，-S 与 -A 的差别也对。“还有很多因素”需要说出至少一个具体因素：例如 SPN 虽不重复，却绑到了错误的服务账户；或者服务使用的密钥/密码、时间、DNS 有问题。

1
setspn -F -Q HTTP/testweb.qy.net
2
setspn -F -X
3
setspn -S HTTP/testweb.qy.net svc_testweb

执行添加前，除了查重，还要核实 Web 服务实际运行身份。微软 Setspn 文档。

Q10：事件日志：别只看 ID（闭卷）#

题目：

qianyue 反复被锁定。请写出查询 Security 日志中最近 20 条 4740 的 PowerShell 命令，并回答：

1. 哪个字段能帮助定位触发锁定的来源机器？
2. 看到 4776，Status=0x0，是成功还是失败？
3. 只凭 4740，能否断定是用户本人输错了密码？下一步会去哪儿找证据？

我的回答：

这个通常用事件查看器看，Get-WinEvent 确实背不下来。

1. 查 Computer 字段
2. 0x0 是成功
3. 不能这么判断，因为这个是用户账户被锁定，并不是密码不正确。 下一步可以去PDC与用户机器上使用管理账号登陆查是否是票据问题。针对查服务、事件的详细日志、是否存在计划任务等。

批改：部分正确。 使用事件查看器人工看没有问题，但题目明确要写 PowerShell 命令，这部分没有答。Status=0x0 表示 4776 验证成功；4740 也确实不能证明用户本人输错密码。

1
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20

字段完整名称是 Caller Computer Name（调用方计算机名），不是笼统的 Computer。事件查看器顶部的“计算机”通常是记录事件的机器，与触发锁定尝试的来源可能不同。先看产生 4740 的 DC 记录及 Caller 字段，再追到来源机上的旧密码、服务、计划任务、保存的凭据与相近时段认证失败事件；不要只凭直觉指定 PDC，也别先把它归为票据问题。微软 4740 字段说明。

Q11：闭卷压轴：加组后依然“拒绝访问”#

题目：

你刚把 qianyue 加入安全组 QYNET-Admin。AD 中查询确认成员关系已存在；用户在 USER01 上仍无法打开 \\QYNET-FS01\Public。USER01 可以解析并连接文件服务器。用户说：“我已经运行过 klist purge，为什么还不行？”

不翻笔记，按排查顺序回答：

1. 至少列出 AD 成员关系、登录令牌、Kerberos 票据、共享权限、NTFS ACL 五层各应检查什么；能记得命令就写命令。
2. klist purge 能刷新哪一层，不能保证刷新哪一层？
3. 如果 whoami /groups 看不到新组，你会怎样处理并复测？
4. 如果看得到新组，下一步该把注意力转到哪里？不要直接假设“肯定是复制没好”。

我的回答：

这一看大概率就是没有同步本地凭据。

AD 成员（DC执行）：

1
Get-ADUser -Identity 'qianyue'
2
Get-ADGroupMember -Identity 'QYNET-Admin' -Recursive

确认关系存在

令牌：

1
whoami /groups

Kerberos：

1
klist

共享权限还没背。

ACL：

1
Get-Acl '\\QYNET-FS01\Public'

批改：未完成，但起点对。 你列出了 AD 成员、whoami /groups、klist、Get-Acl，说明知道要分层；后面三个追问（清票据的边界、如何重建令牌、看到组后查什么）没有回答。开头的“同步本地凭据”也应改成：当前登录会话的访问令牌可能还没有新组 SID，不是用户密码或凭据没同步。

可执行的排查链：

1. 在 AD 中确认 QYNET-Admin 的成员、嵌套关系及组类型；必要时向相关 DC 明确指定 -Server。
2. 在 USER01 上以 qianyue 当前会话运行 whoami /groups。看不到新组时，注销再登录，重新执行同一命令。
3. 同一会话运行 klist 查看目标服务的 cifs/QYNET-FS01... 票据；klist purge 只清票据，不保证重建当前登录令牌。
4. 如果新组已经在令牌里，到文件服务器分别查 SMB 共享权限和共享对应本地目录的 NTFS ACL。可用 Get-SmbShareAccess -Name 'Public'，再确认共享指向的本地路径后对该路径执行 Get-Acl。
5. 复测访问，并留意既有 SMB 会话、显式拒绝项以及实际登录身份。

Get-Acl '\\QYNET-FS01\Public' 可以作为一个观察，但不能代替共享权限检查；要稳定核对 NTFS ACL，最好在文件服务器上确认真实本地路径后查询。微软 Get-SmbShareAccess 文档。

Q12：开卷压轴：新建用户在 DC02 上查不到#

题目：

以下全部是虚构的实验情境，不代表当前 VM 的真实状态。 DC01（192.168.254.10）新建了用户 lab-new01，在 DC01 上能查到，在 DC02（192.168.254.20）上查不到。你收集到：

1
repadmin /showrepl QYNET-CORE02
2
    Source: QYNET-CORE01
3
    Last attempt: failed, 1722 (The RPC server is unavailable)
4

5
从 CORE02 测试 192.168.254.10:135
6
    TcpTestSucceeded: True
7

8
从 CORE02 查询 QYNET-CORE01.qy.net
9
    DNS 返回 192.168.254.99

允许查博客、帮助和官方资料。请写一份简短的排障记录：

1. 根据现有证据，先验证什么、后验证什么？1722 是否足以证明“DC01 的 RPC 服务坏了”？
2. 怎样分别在两台 DC 上查询 lab-new01，避免被默认连接的 DC 误导？
3. 说明 TCP 135 通了为何仍可能复制失败；DNS 返回异常地址时，你会核对哪些记录或配置？
4. 修复后用什么命令验证 DNS 与复制已恢复？如果确实急需手动复制，如何把范围限制到一对 DC、一个命名上下文，避免直接 repadmin /syncall /AdeP？
5. 写出你查阅的 1～2 个资料标题或链接，并指出其中一条对你的判断有什么帮助。

我的回答：

1. 不足以证明 DC01 的复制坏了，目前要先验证 192.168.254.99 这台 DNS 服务器对CORE01的解析异常问题。或是 CORE02 的 DNS服务器配置错误。

2. Get-ADUser -Identity 'lab-new01' -Server $dc $dc 为指定的 DC 参数，不会被默认连接误导。如 Get-ADUser -Identity 'lab-new01' -Server 192.168.254.10。

3. 135通了仅仅是端口通了，还要查服务等其他问题。DNS 返回异常地址肯定查 DC02 的网络配置了。

4. 直接用 Resolve-DnsName 查 DNS 解析，repadmin /showrepl 查，一对一的话用：repadmin /replicate CORE02 CORE01 <上下文即可>。

5. 资料主要还是查询思路，巩固不完善的地方

查阅资料： 在这里记录。#

批改：部分正确。 你没有因 1722 就断言“DC01 的 RPC 服务坏了”，知道 -Server 可避免默认 DC 误导，也写对了 repadmin /replicate 的目标在前、来源在后。问题集中在三个细节：

• 192.168.254.99 是 QYNET-CORE01.qy.net 被解析出的错误地址，题目没有说“这台 DNS 服务器是 .99”。应先区分“问了哪台 DNS”与“DNS 回答了什么”。
• 从 CORE02 测真实 IP 的 TCP 135 成功，只证明 Endpoint Mapper 可达；按名字连接仍可能去错误的 .99，后续动态 RPC 端口也可能被阻断。
• <上下文即可> 只写了占位符；这题需要明确用户所在的域分区 DC=qy,DC=net，并在操作前确认 CORE01 是该分区的有效复制伙伴。

较完整的排障记录可以这样组织：

1
# 在 CORE02 上：先核对本机 DNS 配置，并对比按名称与按真实 IP
2
Get-DnsClientServerAddress -AddressFamily IPv4
3
Resolve-DnsName QYNET-CORE01.qy.net -Type A
4
Test-NetConnection 192.168.254.10 -Port 135
5

6
# 在解析已正确的管理端：明确指定查询哪台 DC
7
Get-ADUser -Identity lab-new01 -Server QYNET-CORE01.qy.net
8
Get-ADUser -Identity lab-new01 -Server QYNET-CORE02.qy.net
9

10
# 修复记录/缓存/配置后，核对复制错误是否消失
11
repadmin /showrepl QYNET-CORE02
12
repadmin /replsummary
13

14
# 确认方向与伙伴关系、且确有紧急需要时，才限于一个域分区
15
repadmin /replicate QYNET-CORE02 QYNET-CORE01 "DC=qy,DC=net"

若在 CORE02 上解析结果异常，还应指定其正在使用的 DNS 服务器查询并对比权威记录，核对 CORE01 的 A 记录、缓存、hosts/多网卡注册，以及必要时的复制伙伴 GUID CNAME；不要直接删除或重建记录。修复后要再次在两台 DC 上分别查 lab-new01，不能只看 /showrepl 不再报错。你附了博客链接，但没有写“哪条资料支持哪一步判断”，下次开卷题补一句即可。微软 1722 排障、Repadmin /replicate 语法、Get-ADUser 的 -Server 参数。

当前掌握度与后续出题方向#

下次开场建议先复测 Q7、Q10、Q11、Q12。尤其 Q11：你已经知道有哪些层，下一步是把它们按“检查 → 修复 → 复测”串起来，而不只是列出命令。

上一篇：Windows AD Practice Day3

下一篇：Windows AD Practice Day5