今天的总体评价#

最明显的进步是 Q11：已能按AD 成员关系 → 当前登录令牌/票据 → 共享与 NTFS 权限 → 复测串起完整排障链。下午也能解释跨林 DNS 查询路径、显式 SMB 凭据与资源所在林的授权方向。主要待补的是：FSMO 五个角色的完整名称、RPC 135 与动态端口的区别、信任“存在”与“实际授权”的证据边界、备份/监控题里的验证与止损步骤。Q12 尚未做跨林共享实验，不纳入掌握度判断。

Q1：已禁用的计算机#

**题目：**找出域中已禁用的计算机，只显示 Name、DNSHostName、DistinguishedName。

我的回答：

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

批改：正确。 对象类型、条件和三列都正确。额外写 -Properties DNSHostName 无碍；当前模块通常也会默认返回该属性。

Q2：已启用的 IT 用户#

**题目：**找出已启用且 Department 为 IT 的用户，只显示 Name、SamAccountName、Department；解释 -Filter、-Properties、Select-Object。

我的回答（交卷原样）：

1
Get-ADUser 'Enabled -eq $false -and Department -eq "IT"' -Properties Department |
2
    Select-Object Name,SamAccount,Department

“一个是筛选，一个是附加属性，一个是 select 选择 print 输出的属性。”

批改：按学习者说明记为交卷笔误；原命令本身不能完成题意。 少了 -Filter，首个字符串会被当成 -Identity 的值；Enabled 要为 $true；输出字段名应为 SamAccountName。下次交卷前花十秒核对“对象、条件、字段”：

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

-Filter 在 AD 侧筛对象；-Properties 要求取回默认集合之外的属性；Select-Object 从已取回的对象中选择显示列，不能代替 -Properties 向 AD 取值。

Q3：用户所属组与组成员#

**题目：**查询 qianyue 属于哪些组；递归列出 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。”

批改：正确。 GroupCategory=Security 才能用于安全授权；Distribution 不能作为文件夹 ACL 的授权组。

Q4：FSMO 角色#

**题目：**不用 netdom 查询两项林级和三项域级 FSMO 角色持有者，写五个角色名称，并说明正常退役 DC 用 transfer 还是 seize。

我的回答：

“Get-ADForest 查两个林；Get-ADDomain 查三个域；不在这里浪费时间了。”

批改：未完成。 两个命令入口选对了，但题目检查的是能否指出五个属性和操作选择。标准写法：

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

正常退役、原角色持有者仍可联系时用 transfer；只有不可恢复、无法正常转移时才考虑 seize，且须评估原 DC 回网风险。下一次可换成故障情境短问，不再反复出同一套五个名称。

Q5：4771 与时间偏差#

**题目：**事件 4771 失败代码 0x25，先怀疑什么？在客户端与 DC 上比较什么？写两条时间查询命令。单凭 4740 能断定用户手输错密码吗？

我的回答：

“0x25 查时间同步。比较时间的同步状态与来源。”

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

“4740 不能直接判断用户输错密码。要看事件中的来源终端，再继续查那台机器保存的凭据或其他原因。”

批改：基本正确。 0x25 优先排查时钟偏差。除了各自的来源和状态，还要比较客户端与实际处理认证的 DC 的时间/偏差；两边都能报出时间源，仍可能相差过大。4740 说明账户被锁定，不说明坏密码一定由用户亲手输入；定位来源后还要查计划任务、服务、保存的凭据等。

Q6：复制错误 1722 的方向#

**题目：**CORE02 从 CORE01 入站复制失败，错误 1722。给出复制摘要、详情命令；说明从哪台向哪台查 DNS/连通性，以及 TCP 135 的证据边界。

我的回答：

1
repadmin /replsummary
2
repadmin /replsummary /errorsonly
3
repadmin /showrepl CORE02

“在 CORE02 上检查 CORE01 的 DNS 与网络连通性。TCP 135 通了并不意味着 RPC 135 通了，服务、防火墙等也要检查。”

批改：方向正确，端口解释需要订正。 从 CORE02 访问 CORE01 的方向是对的；repadmin /showrepl QYNET-CORE02 更便于明确目标。TCP 135 就是 RPC Endpoint Mapper 的监听端口，因此 135 通表示这一入口可达；但实际 AD 复制还需连接由它返回的服务端点，通常涉及动态 RPC 端口。135 通不等于整条 RPC 复制路径可用；继续结合 1722 详情、DNS、服务和防火墙检查。微软 1722 排障

Q7：GPO 三层证据#

题目：Policy-User 被说成已对浅月生效，但用户机器某项设置未变化。检查 GPO 对象、OU 链接/继承、客户端实际应用，并说明每层不能证明什么。

我的回答：

1
Get-GPO -Name 'Policy-User'

“先确认用户对象实际所在 OU；再用 Get-GPInheritance 看该 OU 的直接与继承链接；接着在 USER01 的该用户会话运行 gpresult /h，看适用与拒绝原因；最后查安全筛选、WMI、冲突和客户端事件日志。仍然不能证明在用户机器上生效了。”

批改：基本正确。 这三层已经列出；最后一句需分得更细：

1. Get-GPO 证明对象存在，不证明链接到目标用户的 OU。
2. Get-GPInheritance -Target '<用户OU的DN>' 证明链接/继承关系，不证明客户端已处理；还要考虑阻止继承、安全/WMI 筛选。
3. 在 USER01 的目标用户会话运行 gpresult /scope user /r 或 gpresult /h <报告路径>，证明客户端报告该 GPO 已应用，仍不证明某一设置的最终有效值；需核对该设置范围、优先级、冲突和客户端事件。

Q8：计算机最后登录时间#

题目：LastLogonDate 昨天没变化，能断定计算机昨天没登录吗？如何尽量准确地查最后登录？为什么不直接删 90 天未登录对象？

我的回答：

“不同意。粗筛 LastLogonDate、较精确地查 lastLogon。查询该域每台 DC 并取最大值。有些对象需要一直在那里，删除可能导致异常。”

批改：方向正确；解释略短。 LastLogonDate 是由会复制、但不会每次登录都立刻更新的 lastLogonTimestamp 转成的易读时间；它没变化不证明昨天未登录。lastLogon 不在 DC 间复制，所以需查询该域每台 DC，取最大有效值。库存机、冷备机、定期开机设备可能长期没有新时间；应先核对资产和业务，再按报告—确认—隔离观察—删除流程处理。微软说明

Q9：误删用户的恢复#

**题目：**误删测试用户时，有人建议整机恢复 DC。给出更小范围的恢复方案、恢复后验证项，并说明“系统状态备份成功”是否等于可恢复。

我的回答：

“先确认 AD 回收站功能是否启用；启用时在可恢复期内找删除对象并恢复。删除时保留的链接属性通常会一并恢复；微软文档举例：用户自动重新获得当时的组成员关系与相应访问权。仍应核对组、资源当前 ACL、跨域复制、用户现有令牌。删除后别人改过的 ACL、外部系统配置或用户会话不会自动回到过去。”

批改：恢复机制理解正确；操作闭环未写全。 这里要特别订正旧笔记里的笼统说法：回收站在删除前已启用、对象仍处于可恢复阶段时，链接属性会保留，用户可恢复原组成员关系；不是一律需要手动重新加组。仍须核查当前实际授权。微软 AD 回收站文档

可先只读定位，再核对唯一标识后恢复测试对象；Restore-ADObject 是写操作，不能把下列占位符直接执行：

1
Get-ADOptionalFeature -Filter 'Name -eq "Recycle Bin Feature"'
2
Get-ADObject -Filter 'isDeleted -eq $true' -IncludeDeletedObjects |
3
    Select-Object Name,ObjectGUID,DistinguishedName
4

5
# 确认身份、原 OU 和审批后才执行：
6
Restore-ADObject -Identity '<已确认的对象 GUID>'

备份作业显示成功只证明当时作业报告完成，不证明备份文件仍可读、所需版本存在，或在隔离环境中能按要求恢复。要核对 wbadmin get versions 并定期做恢复演练；不应为了单个误删用户直接恢复整台健康 DC。

Q10：磁盘空间、数据库与复制#

**题目：**DC 的 C 盘持续下降且出现复制告警。分别检查磁盘、ntds.dit 和复制；解释删除对象后文件不变小的原因，以及不应贸然做什么。

我的回答：

1
Get-PSDrive C | Select Used, Free
2
Get-Item "C:\Windows\NTDS\ntds.dit"
3
repadmin /replsummary

“AD 在线整理会回收数据库内部空间，但不会直接缩小磁盘上的 ntds.dit；回收站还会保留可恢复对象。看长期趋势，而非一次删除后的瞬时变化。”

批改：检查与解释正确；止损步骤未写。 Get-Item 最好选出 Length 便于对比；复制异常要继续看相关 DC 的 repadmin /showrepl。不能为了腾空间直接删除 AD 对象或 ntds.dit，也不能未经备份、评估和维护窗口就对生产 DC 做离线压缩：

1
Get-PSDrive C | Select-Object Used,Free
2
Get-Item 'C:\Windows\NTDS\ntds.dit' | Select-Object FullName,Length
3
repadmin /replsummary
4
repadmin /showrepl QYNET-CORE02

还应查是数据库、日志、备份还是其他目录占空间；磁盘告警与复制告警同时出现，不自动证明前者导致后者。

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

题目：qianyue 加入安全组且据称共享已授权，在 USER01 上仍被拒绝访问。按至少四层证据、运行位置、修复与复测组织答案，并区分票据、令牌、共享与 NTFS ACL。

我的回答：

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

批改：完整，本日最佳。 已把“AD 保存的成员关系”“当前会话令牌”“Kerberos 服务票据”“文件服务器授权”分清，并写出复测。再加一个实施前确认：题目只说“某个安全组”，不要先假定它一定是 QYNET-Admin；共享名、服务器名也要从现场核对。实际修复动作应依查到的原因选择，不能见到拒绝就盲目改 ACL。

Q12：开卷压轴——两林共享访问#

**题目：**规划 qy.net 用户访问 MFNET 林中成员服务器共享：双方 DNS、时间、信任方向与认证范围、账号/组授权、客户端访问验证，并设计可回退的故障实验。

我的回答：“我还没做完两林之间的共享，稍后在 VM 上进行操作。”

批改：待做，不计分。 没有把计划写成已执行，是正确的记录方式。实验时按确认 MFNET 实际域名与 IP → 两林各自健康 → 双向解析 → 信任方向/认证范围 → 资源共享及 NTFS 授权 → 目标用户实际访问 → 故障与回退复测留证据。这里暂不附“成功输出”，待 VM 实验后补真实结果。

Q13：信任对象三个字段#

**题目：**解释 MFNET 侧 BiDirectional、ForestTransitive=True、SelectiveAuthentication=False，并指出这些字段不能证明什么。

我的回答：“查了资料；双向认证、森林传递信任，对方林下的域会被信任；没开选择性认证，开启后对方用户默认不能访问本域资源。”

批改：开卷基本正确。 双向表示两侧都有身份验证路径；林传递信任可覆盖两林内部的域，不自动延伸到第三个林；未启用选择性身份验证表示当前不是逐台目标计算机先授 Allowed to Authenticate 的模式。漏答的是：这些属性不能证明信任已验证健康，更不能证明用户拿到了共享/NTFS 权限或实际访问成功。微软林信任说明

Q14：SMB 用了谁的凭据#

**题目：**MFNET-CORE01 上连接 QYNET NETLOGON，UserName=MF\Administrator、Credential=qy\Administrator。实际向对方提供哪个身份？为何不能据此证明 MF 用户跨林访问？

我的回答：“UserName 是发起连接的本地用户；这次向 QYNET 提供 Credential=qy\Administrator。它绕过 MFNET 身份，直接用 QYNET 账户登录。”

批改：关键判断正确。 当前本地会话是 MF 管理员，但 SMB 连接提供的是显式 qy\Administrator 凭据，所以不能把这次成功算作 MF 普通用户获准访问 QYNET 资源。不必绝对断言“整个连接根本没走信任”；准确说法是：这条证据本身不需要林信任，也不足以验证林信任的用户访问路径。下一步要用 MF 普通测试用户、QYNET 成员机测试共享及明确 ACL 验收。微软 Get-SmbConnection 文档

Q15：正常退役 FSMO 持有者#

**题目：**仍在线的 PDC Emulator/RID Master 持有者要退役，用 transfer 还是 seize？暂时联系不上先查什么？

我的回答：“transfer。暂时联系不上要检查 DC 是否运行，PDC 的账号相关服务、RID 是否还能分配安全对象。”

批改：选择正确，排查范围需扩展。 临时失联先查 DC 电源/网络、DNS、时间、复制、相关事件日志，以及在其他 DC 上核实当前角色持有者；确认可恢复路径和业务影响，再决定恢复原 DC 或正常转移。不能因为暂时联系不上就 seize。PDC 并非唯一做普通账号验证的 DC，RID 故障也不等于立刻不能创建任何对象，需看各 DC 的 RID 池状态。

Q16：CORE02 是否能解析 MFNET#

**题目：**从 QYNET-CORE02 的本机 DNS 查询 MFNET A 与 DC 定位 SRV 记录，解释成功的边界及两台 QYNET DC 结果不一致时先查什么。

我的回答（VM 关键输出）：

1
Resolve-DnsName MFNET-CORE01.mf.net -Server 127.0.0.1
2
# 返回 A 192.168.254.15，同时也显示一个 fe80:: 开头的 AAAA 地址
3

4
nslookup -type=srv _ldap._tcp.dc._msdcs.mf.net 127.0.0.1
5
# 返回 MFNET-CORE01.mf.net，端口 389，地址 192.168.254.15

“这只证明 CORE02 的 DNS 能解析 MFNET 的 A 与 SRV，不能证明信任密码、账户、Kerberos、目标服务健康。”

批改：实测与证据边界基本正确。 想只看 A 记录可加 -Type A；fe80:: 是链路本地 IPv6 地址，本题不要把它当成 MFNET 可跨网段访问的证明。若 CORE01 正常、CORE02 不正常，先查 CORE02 是否收到条件转发器（GUI 或 Get-DnsServerZone -Name mf.net）、两台 DNS 的配置/复制及缓存，再判断下游网络；仅“能解析”本身也不证明转发器究竟通过哪条路径生效。微软 DNS 区域查询文档

Q17：两边的信任对象#

**题目：**两边查询对方林的信任属性，并解释信任存在与资源访问之间的差距。

我的回答：

1
# MFNET 侧
2
Get-ADTrust qy.net |
3
    Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication
4

5
# QYNET 侧
6
Get-ADTrust mf.net |
7
    Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication

“输出复制不了；中间还差‘信任关系可用’，建立不等于可用。”

批改：查询写法可用，真实结果未留存。 前面聊天里 MFNET 侧确实给过 BiDirectional/ForestTransitive=True/SelectiveAuthentication=False 的实际输出；本题未留下 QYNET 侧结果，不能记为两边实测完成。还应把差距拆成两步：信任验证可用，以及普通用户在正确方向、正确资源上有共享和 NTFS 授权并实际访问成功。即便信任验证通过，也不自动授权。

Q18：直接问对方 DNS 与问本机 DNS#

**题目：**直接向 MFNET DNS 查询成功，QYNET 本机 DNS 查询失败为何不矛盾？条件转发后路径怎样变？MFNET DNS 离线会怎样？

我的回答：“两次走的不是同一条路；直接问 MFNET 权威 DNS 能查到，本机 DNS 在没记录时查不到。加条件转发后，mf.net 的查询交给 MFNET DNS。”

批改：前两问正确。 目标 DNS 离线后，本机 DNS 转发查询可能超时或失败；已有缓存可能暂时还能应答，因此不会保证断线瞬间所有查询一齐失败。还要区分 DNS 失败与已建立的会话/缓存仍在工作。

Q19：单向信任思想实验#

**题目：**若只允许 MFNET 普通用户访问 QYNET 测试资源，哪边是信任方？画账号→资源箭头，并说明如何核实向导方向。

我的回答：“QYNET 信任 MFNET 资源、QYNET 提供资源；MFNET 用户 → QYNET 测试资源。”

批改：资源方向判断正确，信任对象说法需改。 是QYNET 信任 MFNET 对其用户身份的认证，不是信任 MFNET 的资源；资源在 QYNET。向导中从 QYNET 这一侧选择只允许对方林用户访问本林资源的单向向外（outgoing）信任，从 MFNET 侧看则为 incoming。方向名称是相对本侧而言；务必结合向导解释和创建后的 Direction 双侧复核。本题只是思想实验，不修改当前双向信任。微软信任方向定义

Q20：选择性身份验证#

**题目：**若改为选择性身份验证，跨林用户访问 QYNET 成员机除共享/NTFS 权限外还缺什么？加在哪个对象？

我的回答：“加在 QYNET 中目标成员机的 Computer Object 上。”并附了两条微软旧版文档链接。

批改：位置正确，漏了权限名称。 还须授予相应外林用户/组对目标计算机对象的 Allowed to Authenticate 权限；这与文件共享及 NTFS ACL 是不同层。你给了资料链接，下一次把“资料支持哪一步”也写清楚。本题只解释，不改变当前 SelectiveAuthentication=False 的设置。微软选择性身份验证说明

Q21：跨林组与共享 ACL#

**题目：**MF 普通用户只读访问 QYNET 成员机测试共享，设计全局组、域本地组及资源权限链，说明为何不用 MF 管理员。

我的回答：“MFNET 建全局安全组，QYNET 建域本地安全组；MF 普通用户加入 MF 全局组，MF 组加入 QY 本地组，最后给 QY 成员机共享与 NTFS 权限。管理员不代表普通用户，还可能绕过部分限制。”

批改：基本正确。 写得更精确一些：MF\测试用户 → MF 全局安全组 → QY 域本地安全组 → 测试共享的共享权限及 NTFS 读取权限。不是“MFNET 整个域加入 QYNET 组”，而是具体 MF 全局安全组加入；两个权限层都要授给 QY 域本地组。测试普通用户才能证明最小权限方案，管理员可能因额外权限掩盖 ACL 问题。微软安全组作用域说明

Q22：当前身份、SMB 凭据与票据#

题目：nltest 成功但跨林 SMB 失败时，怎样在客户端分开看当前登录身份、已有 SMB 连接凭据和 Kerberos 票据？各自的证据边界是什么？

我的回答：“whoami、klist、Get-SmbConnection；它们除了自己显示的东西，不能证明其他层，例如 whoami 不证明 SMB 连接用了这个身份或 Kerberos 有效。”

批改：三个工具选对了，解释可以落到字段。 whoami 看本地会话身份，不证明网络连接凭据；Get-SmbConnection 看现有连接的 UserName/Credential/ShareName，不证明资源 ACL 已按预期配置；klist 看当前登录会话票据（如目标 cifs/...），没有票据不自动证明没有访问，还要考虑 NTLM、连接是否仍在或查询的登录会话是否正确。建议每次写“命令 → 实际关键字段 → 结论”。

Q23：SPN 与客户端票据#

**题目：**只读查 HTTP/testweb.qy.net 被谁注册、全林重复 SPN、客户端票据；为何不随意用 -A？

我的回答：

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

“-A 不检查重复，重复会导致 Kerberos 验证问题。”

批改：SPN 查询、查重及风险判断对；漏了 klist。 用 klist 在客户端相应登录会话查看是否有目标服务票据；若要看加密类型等详情，可按该系统支持的 klist 参数查。微软明确建议新增 SPN 用 -S 查重，不用 -A 盲加；但本题不做新增操作。微软 setspn 文档

Q24：4740、4771 与 4776#

**题目：**查询最近 20 条锁定事件，找来源字段，区分 Kerberos 预认证失败与 NTLM 凭据验证。

我的回答：“Get-WinEvent -FilterHashtable 配合 ID 4740，但没有背全，实际会打开事件查看器；4771 是 Kerberos 预认证失败，4776 是 NTLM 账户凭据验证。”

批改：概念方向正确；命令与 4740 来源字段未写。 用事件查看器当然可以，不必为背命令硬造输出。若要练 PowerShell：

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

在事件详情找 Caller Computer Name；它帮助定位来源机器，但不等于该用户亲手输错密码。4771 是 Kerberos 预认证失败；4776 是 NTLM 凭据验证尝试，既可能成功也可能失败，要看状态码，0x0 表示成功。微软 4771、4776 说明

Q25：跨林时间偏差#

**题目：**跨林 Kerberos 不稳定时，查询本机时间源/状态，并测另一林 DC 的时间偏差。

我的回答：

1
w32tm /query /source
2
w32tm /query /status
3
# 在 QYNET-CORE01 上对比 QYNET-CORE02
4
w32tm /stripchart /computer:QYNET-CORE02 /samples:5

批改：命令会写，但测量对象未贴题意。 CORE01 → CORE02 是同林 DC时间差，不能直接回答与 MFNET 的跨林偏差。应从 QYNET 一侧对 MFNET-CORE01 比较，例如：

1
w32tm /stripchart /computer:MFNET-CORE01.mf.net /samples:5 /dataonly

若远端时间服务未回应，这只能说明本次测量失败，不能直接断定双方时钟不同步。题中没有贴 VM 输出，故不记录为已测出偏差。

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

Q26～Q32 未答且已从临时卷移除，不计掌握度。下一次不用补齐“欠的七题”；优先做一两个实际 VM 小实验，恢复节奏。

上一篇：Windows AD Practice Day5