今天的总体评价#

用户筛选、组查询、FSMO 的基本判断，以及“成员关系 → 登录令牌 → 票据 → 共享/NTFS 权限”的分层思路已经比较稳。主要问题是知道方向，但写命令时偶尔选错对象、测错通信方向，或漏掉关键字段。Q10 的三层模型交卷时会说、命令未写出；实操后已能逐层读懂真实输出。Q12 尚属新知识，不与复习题同等评分。

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输出的属性。

批改：完整。 命令正确。更准确地说，-Filter 让 AD 筛选对象，-Properties Department 请求返回非默认属性，Select-Object 从已返回的对象中挑显示列；Select-Object 不会替你向 AD 补取属性。

Q2：组、成员与权限（闭卷·热身）#

**题目：**分别写命令：① 查看 qianyue 属于哪些组；② 递归查看 QYNET-Admin 的成员；③ 查看 QYNET-Admin 的组作用域与组类型。若要用于文件夹 ACL，组类型应是什么？

我的回答：

1
Get-ADPrincipalGroupMembership -Identity 'qianyue'
2
Get-ADGroupMember -Identity 'QYNET-Admin' -Recursive
3
Get-ADGroup -Identity 'QYNET-Admin' | Select-Object GroupScope, GroupCategory

ACL 应为 Security

批改：完整。 三条命令方向正确。用于权限授权的是 Security 安全组；Distribution 通讯组不能直接承担文件夹 ACL 授权。

Q3：计算机与登录时间（闭卷·热身）#

**题目：**① 找出已禁用的计算机对象，只显示 Name、DNSHostName、DistinguishedName。② 为什么 LastLogonDate 适合长期不活跃粗筛，却不能精确判断“今天有没有登录”？若要尽可能精确地取一台机器的最后登录时间，应怎样查？

我的回答：

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

长期粗筛使用 LastLogonDate 即可，因为它并不是实时同步，可能是几天同步一次 。如果需要精确查的话，使用 LastLogon 更准确。

批改：部分正确。 时间属性的方向对，但题目找的是计算机，不能用 Get-ADUser；输出也多选了 LastLogonDate。先看题目中的对象类别，再选命令入口：

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

LastLogonDate 是根据会复制但不实时更新的 lastLogonTimestamp 转换得到的易读日期，适合筛长期不活跃对象。lastLogon 不在 DC 间复制；要求尽量准确时，查询该域每台 DC 对这台计算机保存的值并取最大值，不能只查 PDC 或随便挑几台。微软属性说明

Q4：时间与认证（闭卷·热身）#

**题目：**某客户端报 Kerberos 预认证失败，事件 4771 的失败代码为 0x25。先想到什么问题？写出两条检查本机时间源与状态的命令，并说明为什么“服务器时间看起来差不多”还不足以结束排查。

我的回答：

1
0x25 为时间偏差过大。
2

3
w32tm /query /source
4
w32tm /query /status
5

6
Kerberos 时间尽可能精确同步，偏移超过五分钟就会导致出现问题。以及服务器时间如果看起来差不多则意味着时间源同步依旧可能存在问题，需要在不同DC上使用w32tm进一步排查source。

批改：基本正确。 0x25 与两条命令都对。下一步要关注出错客户端与实际处理认证的 DC 之间的时间差，并确认各自同步源/状态；肉眼看时间相近、只看源名称，都不能给出精确偏差。默认 Kerberos 时钟容差通常为 5 分钟。微软 4771 失败代码说明

Q5：FSMO：退役与故障接管（闭卷）#

题目：QYNET-CORE01 持有五个 FSMO 角色，计划正常退役；另一种情境是它彻底损坏、无法恢复。两种情境分别应选 transfer 还是 seize？写出五个角色的名称与林级/域级划分，并解释为什么不能对仍在线的原角色持有者随意 seize。

我的回答：

1
前者 transfer ，后者 seize。
2
林：架构主机、域命名
3
域：RID、PDC、基础结构
4

5
随意 seize 会导致 FSMO 角色重复，在处理某些事项或者是功能会引发域控异常。

批改：完整。 林级两个：Schema Master、Domain Naming Master；域级三个：PDC Emulator、RID Master、Infrastructure Master。健康退役应正常转移；只有原持有者无法恢复、无法正常转移时才考虑强制夺取，并按角色制定旧 DC 的后续处置，避免旧持有者再次上线造成角色冲突。

Q6：复制失败：证据够不够（闭卷）#

题目：repadmin /showrepl QYNET-CORE02 报 1722。从 CORE02 到 CORE01 的 TCP 135 可连通。能否据此断定“RPC 没问题，只剩 AD 数据库损坏”？按先后顺序写出至少四项还应核对的证据或命令，并说出 repadmin /replsummary 与 /showrepl 的用途区别。

我的回答：

TCP 135 可连通，但并不意味着 DNS 解析是否成功、也不意味着 服务 是否正常运行、同时也可以查复制日志详细了解报错、RPC 135 也可以查。

1
Resolve-DnsName QYNET-CORE01.qy.net # DNS
2
repadmin /showrepl QYNET-CORE02 /verbose # 详细日志
3
Get-Service -ComputerName QYNET-CORE02 -Name RpcSs,RpcEptMapper,Netlogon,NTDS,KDC,DNS # 服务
4
Test-NetConnection QYNET-CORE02 -Port 135 # RPC 135

一个是快速整理整个域复制摘要，一个是针对于一台机器查询它的复制情况。

批改：部分正确。 没有草率认定数据库损坏，DNS、服务和详细错误也都值得查；但题目强调的是CORE02 从 CORE01 拉取复制。既然已知从 CORE02 到 CORE01 的 135 可连通，就不要再从管理机测 CORE02:135 来重复证明另一个方向。下一步重点是名称是否解析到正确的 CORE01、RPC Endpoint Mapper 返回的动态端口是否可达、两边相关服务/防火墙以及事件日志：

1
# 以下网络检查在 CORE02 上执行，目标是 CORE01
2
Resolve-DnsName QYNET-CORE01.qy.net
3
Test-NetConnection QYNET-CORE01.qy.net -Port 135
4

5
# 查 CORE02 的入站复制详情和全域摘要
6
repadmin /showrepl QYNET-CORE02 /verbose
7
repadmin /replsummary

/replsummary 看整体错误摘要，/showrepl 看指定 DC 的各命名上下文、伙伴和尝试结果。TCP 135 是 RPC Endpoint Mapper，135 成功不代表随后协商的动态 RPC 端口可用；也不足以归因于 AD 数据库。Get-Service -ComputerName 适用于 Windows PowerShell 5.1；在 PowerShell 7 中该参数不可用，可在目标机本地查或用远程会话。微软 1722 排障说明

Q7：空 OU 与孤立 SID（可翻笔记）#

**题目：**巡检结果显示某 OU 没有直接子对象；文件共享的 ACL 中还出现 S-1-5-21-... 形式的裸 SID。① 为什么不适合仅用 -Properties Children 判定“空 OU”，更可靠的方法是什么？② 裸 SID 能否单独证明账户已删除？③ 移除前还要核对什么？

我的回答：

1. 要判断一个 OU 有没有直接子对象，对每个 OU 做一次 OneLevel 查询即可；子对象可能是用户、组、计算机或子 OU，不应只查子 OU。
2. 裸 SID 只是线索，不是“账户已被删除”的证明。身份解析也可能因为域控暂时不可达、信任关系异常、外域账户或权限不足而失败。确认账户与资源用途之前，不要批量删除 ACL 项；删除 ACL 也不会删除文件。
3. 重点不是“找到就删”，而是先弄清对象是否仍被业务、权限或策略引用。

批改：基本正确。 已经抓住“直接子对象”和“身份解析失败不等于删除”。若要落成只读命令，可对某个指定 OU 查询所有类别的直接子对象：

1
Get-ADObject -Filter * -SearchBase 'OU=Example,DC=qy,DC=net' -SearchScope OneLevel |
2
    Select-Object Name,ObjectClass

返回空才说明这次查询没有找到直接子对象；移除前仍需确认 GPO 链接、委派权限、脚本引用、业务归属与删除保护。裸 SID 还可能涉及外域主体、信任中断或 DC 暂时不可达，不要自动清理 ACL。

Q8：事件日志：谁触发了锁定（闭卷）#

**题目：**用户 qianyue 连续被锁定。写出查询最近 20 条 4740 的 PowerShell 命令；指出定位来源机器的完整字段名。若同一时间看到 4776 且 Status=0x0，能否当作“密码错误”证据？下一步怎样找可靠来源？

我的回答：

1
Get-WinEvent 的指令我觉得要是用到的话还得查，确实背不下来。
2
来源机器字段名为 "Computer"
3
0x0 意味着这是成功的，并不能作为密码错误的证据。
4
想要找到更可靠的依据，还是要去来源机器字段名上进行进一步查询。（如用户凭据等）

批改：部分正确。 0x0 是成功，不能拿它证明密码错误。缺的是命令和字段名：

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

4740 里的来源字段是 Caller Computer Name，而事件顶部的 Computer 通常是记录该事件的机器，两者不能混为一谈。先在产生 4740 的 DC 上定位 Caller，再到来源机查相近时间的认证失败、保存的凭据、服务与计划任务；如果 Caller 信息为空或不可靠，还要结合其他 DC 日志交叉核对。微软 4740 字段说明

Q9：误删后的恢复选择（可翻笔记）#

**题目：**管理员误删用户。按顺序说明：① 确认 AD 回收站是否可用；② 可用时优先的恢复路径；③ 何时才考虑系统状态备份与 DSRM；④ 恢复后为何核查组归属和资源权限。不在真实 VM 执行恢复。

我的回答：

1
Get-ADOptionalFeature -Filter 'Name -eq "Recycle Bin Feature"' |
2
    Select-Object Name,EnabledScopes

查 EnabledScopes 是否为空，若列出林的配置命名上下文，则已启用。

不要直接拿删除前的 DN 还原。先核对 ObjectGUID、原位置 lastKnownParent 和对象类型，避免同名对象误选。

恢复 DC 的 AD 系统状态前，应进入 DSRM（目录服务还原模式），并确认 DSRM 密码与可用备份。 这是高风险操作；应先明确恢复目标、健康 DC、复制拓扑及恢复后重启步骤，不要在正常服务中的域控上直接试跑。一般情况下启用 DSRM 的话，意味着这台服务器问题已经很大了。无法进入到正常的系统中进行还原操作。

还原后按既定恢复方案重启、检查 AD DS/DNS/SYSVOL 与复制。普通系统状态还原不是“把误删对象强制恢复给其他 DC”；在还有健康复制伙伴时，非权威还原之后通常会从伙伴接收较新的目录数据。单个对象误删，应先看回收站。

批改：部分正确。 风险意识很好，检查 EnabledScopes 和按 GUID 核对身份都对；中间漏了真正的回收站恢复链。下面是示意命令，不在练习 VM 执行恢复：

1
# 先只读查找，核实 ObjectGUID、对象类型和原位置
2
Get-ADObject -Filter 'isDeleted -eq $true' -IncludeDeletedObjects `
3
    -Properties lastKnownParent,ObjectGUID |
4
    Select-Object Name,ObjectClass,ObjectGUID,lastKnownParent
5

6
# 人工确认目标对象后才恢复；此行仅作语法示例
7
Restore-ADObject -Identity '<确认过的 ObjectGUID>'

若回收站不可用、对象不在保留期内或需要更大范围的 AD 恢复，再规划备份/DSRM，并明确非权威与权威恢复的差异。DSRM 是主动进入的维护/恢复模式，不表示 DC 必然已经无法正常启动。 恢复后核查组归属、账户状态与资源 ACL 的实际效果；是否保留了某项关联，取决于删除与恢复条件，不能未经验证就断定全部丢失或全部恢复。微软 AD 回收站文档

Q10：GPO：存在、链接、已应用（闭卷；交卷后实操）#

题目：Get-GPO -Name 'Policy-User' 能查到对象，但 USER01 登录后没有得到预期设置。分别写出检查 GPO 对象、目标 OU 的链接/继承、客户端实际处理结果的命令。Get-GPO -All 能否证明策略已应用？“被拒绝”列表找不到它，能否证明链接没有问题？

我的回答（交卷时）：

能查到 GPO 对象 ≠ GPO 会被应用。要分三层查：GPO 本身、链接/继承、客户端实际处理。 命令还没背 … 手把手带我做一次吧！

批改：交卷时思路正确，命令未完成。 Get-GPO -All 仅列出对象，不能证明对某用户或计算机已应用；“被拒绝”列表没有它，也不能反推链接一定正确。随后在 VM 上按三层做了只读实操，以下输出来自学习者实际运行并贴到对话中的结果，不是虚构示例：

第一层：对象存在吗？ 在装有 GroupPolicy 模块的管理端运行：

1
Get-GPO -Name 'Policy-User' |
2
    Select-Object DisplayName,Id,GpoStatus
3

4
DisplayName Id                                            GpoStatus
5
----------- --                                            ---------
6
Policy-User d5199290-648b-49fa-a341-1088b2d4288b AllSettingsEnabled

这证明对象存在，用户/计算机配置没有被整体禁用，但不证明链接或实际应用。

第二层：目标用户位于哪里，策略能继承到那里吗？

1
Get-ADUser -Identity qianyue |
2
    Select-Object Name,DistinguishedName
3

4
Name DistinguishedName
5
---- -----------------
6
浅月 CN=浅月,OU=User,OU=Admin,OU=Organization,DC=qy,DC=net
7

8
Get-GPInheritance -Target 'OU=User,OU=Admin,OU=Organization,DC=qy,DC=net' |
9
    Format-List Path,GpoInheritanceBlocked,GpoLinks,InheritedGpoLinks
10

11
Path                  : ou=user,ou=admin,ou=organization,dc=qy,dc=net
12
GpoInheritanceBlocked : False
13
GpoLinks              : {}
14
InheritedGpoLinks     : {Policy-User, Software-GPO, Default Domain Policy,
15
                         Policy-WSUS}

CN=浅月 是用户对象；-Target 填其所在 OU 的 DN。GpoLinks : {} 只表示这个 OU 没有直接链接；Policy-User 出现在 InheritedGpoLinks，说明它在此处作为继承到的链接可见。这里还不能替客户端宣布“已应用”。Get-GPInheritance 文档

第三层：受影响用户的客户端实际处理了吗？ 在 USER01 的 qy\qianyue 登录会话中运行：

1
gpresult /scope user /r
2

3
qy\qianyue 的 RSOP 数据，位于 QYNET-USER01 上: 登录模式
4
...
5
上一次应用组策略的时间: 于 2026/9/24，15:14:17
6
应用的组策略来源于:     QYNET-CORE02.qy.net
7
...
8
已应用的组策略对象
9
-------------------
10
    Policy-User
11

12
下列组策略对象被筛选排除，因此没有应用
13
---------------------------------------
14
    本地组策略
15
        正在筛选: 没有应用 (空)

由此可判定：在这份 RSoP 报告中，Policy-User 被列为已应用。但报告于 9 月 29 日生成，上一次应用时间是 9 月 24 日，值得继续核实是否有更新；如果 VM 一直未开，这个时间也未必代表故障。题目没提供“预期设置”具体是什么，所以不能据此判断某项设置为何没达到预期。若继续真实排障，先明确该设置及其用户/计算机配置归属，再比较 GPO 修改时间、设置内容和客户端实际状态。gpresult 文档

记忆句：对象在，不等于链得到；链得到，不等于客户端已应用；报告已应用，也不等于每项预期设置都生效。

Q11：闭卷压轴：加组后还是拒绝访问#

题目：qianyue 已被加入安全组 QYNET-Admin，但在 USER01 上访问 \\QYNET-FS01\Public 仍被拒绝。DNS 和 SMB 连通，AD 成员关系已确认。按顺序从当前身份、登录令牌、Kerberos 票据，到共享权限和 NTFS ACL 写最小排障链；说明 klist purge 的边界。

我的回答：

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 会话、显式拒绝项以及实际登录身份。

批改：完整。 这次按顺序形成了“AD → 当前登录身份与令牌 → 服务票据 → 服务器侧两层授权 → 复测”的闭环。要继续区分：klist purge 清的是票据，不保证当前登录会话的访问令牌包含新组 SID；令牌没有新组时，注销重登再用 whoami /groups 验证。令牌已有组时，不要直接归因于复制，先检查共享权限、NTFS ACL、显式拒绝与当前连接身份。

Q12：开卷压轴：MFNET 与 QYNET 跨林信任预案#

**题目：**拟把 MFNET-CORE01 建为独立林首台 DC，再与 qy.net 建信任。两台 VM 在 VMnet1 192.168.254.0/24；QYNET-CORE01 为 .10，新机 DHCP 地址为 .136，DHCP 池为 .128～.254。规划静态 IP/DNS、双向解析、建信任前检查、信任与资源访问的验证；只写方案，不执行变更。

我的回答：

我还没学完，你直接给答案吧！

批改：新内容，不计分。 下面是学习用参考方案，不表示 VM 已完成配置。

1. 地址与本林 DNS。 选 192.168.254.0/24 中 DHCP 池 .128～.254 之外且未占用的主机地址，掩码 /24（255.255.255.0）。.136 是动态租约，手动固定它可能与将来的租约冲突。候选地址先核对 VM/主机网卡配置、DHCP 租约、现有静态地址清单和实际占用；单凭一次 Ping 不通不能保证空闲。纯 VMnet1 同网段实验不需要虚构网关；如另有外网/路由需求，单独设计。新林首台 DC 同时运行 DNS 时，DNS 客户端指向本机 DNS 地址，不要把 QYNET DNS 当作本林主 DNS 或备用 DNS。微软 DC DNS 客户端建议

2. 双向域名解析。 同网段只证明可能直接 IP 通，不保证能定位对方域控。在 QYNET DNS 上为 MFNET 的实际 DNS 域名配置条件转发到 MFNET DNS；在 MFNET DNS 上为 qy.net 配置条件转发到 QYNET DNS。先确认双方域名、DNS 地址、DNS 服务正常，再分别从两边查询对方 DC 的 A 与域控定位 SRV 记录。例如在 QYNET 侧：

   1
   Resolve-DnsName MFNET-CORE01.<MFNET域名> -Type A -Server <QYNET-DNS-IP>
   2
   Resolve-DnsName _ldap._tcp.dc._msdcs.<MFNET域名> -Type SRV -Server <QYNET-DNS-IP>

   在 MFNET 侧把域名换成 qy.net、DNS 服务器换成 MFNET DNS，作对称检查；其中占位符必须替换为确认过的真实值，不能直接复制执行。微软 DNS 条件转发说明

3. 信任前与信任后。 核对两边 DC 健康、时间偏差、DNS 解析、双向 IP 可达、所需端口与防火墙；尤其不能把 TCP 135 通当成所有 RPC 通。再决定信任方向、森林/外部信任类型与认证范围。建好后可查信任对象/验证信任状态，但这只证明“身份可跨边界被识别/验证”的条件之一；还要挑一项测试共享资源，明确授予跨林用户或组相应的共享与 NTFS 权限，再用实际用户访问验证。信任不等于自动授权。 微软 AD 域与信任的防火墙要求、Get-ADTrust 文档

这题的核心区别是：同网段 ≠ 互相解析；能解析 ≠ 信任建成；信任建成 ≠ 用户自动能访问资源。

当前掌握度与下一次练习方向#

下次可优先复测 Q3、Q6、Q8、Q9、Q10；Q12 等学过信任后再重新出题，不急着背答案。

上一篇：Windows AD Practice Day4

下一篇：Windows AD Practice Day6