Q1｜“能访问”证明了什么？（闭卷·热身）#

在 MFNET-CORE01 打开 \\QYNET-CORE01\netlogon，弹窗后输入 qy\Administrator，访问成功；Get-SmbConnection 显示当前 UserName=MF\Administrator、Credential=qy\Administrator。这次访问分别证明了什么、不能证明什么？不要只回答“信任通了”。

我的回答： 能证明： DNS正常解析可以在 MFNET 中正常访问 QYNET，且建立起了单向信任（目前无法证明双向）。 且信任验证使用的为 QYNET 的 Admin 凭据，且凭据使用的对象为 MF 的 Admin 凭据。

无法证明： MFNET 使用自己的用户凭据不一定可以访问。 MFNET 使用自己的普通用户并使用此 QYNET-Admin 的凭据不一定能访问。 netlogon 不一定开放了对 MFNET 用户的相关权限。

**复习提示：**这次成功的关键证据是 SMB 使用了 qy\Administrator 凭据。主机名能被访问不一定严格证明 DNS 条件转发器已正确复制（可能走缓存等解析路径）；更不能证明任一方向的信任验证通过。UserName 对应本地会话，Credential 才是 SMB 连接实际使用的身份。

Q2｜时间与事件（闭卷·热身）#

某用户跨林认证失败，DC 上有事件 4771，失败代码 0x25。你首先怀疑什么？该比较哪两端的时间？写出两条查看本机时间源/状态的命令。若另看到 4776，能直接断定密码错误吗？

我的回答： 4771 和 0x25 首先怀疑时间问题。比较终端与DC（PDC）的时间。 命令为： w32tm /query /status w32tm /query /source 比较状态与时间源。

4776不能直接判断为密码错误，4776为NTLM 账户凭据验证，也是要看具体的状态码的。

复习提示：方向对。时间应比较发起认证的客户端与实际处理这次认证的 DC，跨林链路还要考虑两侧 DC 的时间；不必只盯 PDC。4776 既可能成功也可能失败。

Q3｜条件转发器：解析成功还不够（开卷·VM 可选只读）#

请在 QYNET-CORE01 和 CORE02 分别确认：① 本机 DNS 能否解析 MFNET-CORE01.mf.net 的 A 记录；② 本机是否真的保存了 mf.net 的条件转发器。写出只读查询命令或 GUI 路径；若实测，贴每台的关键结果。解释为什么“两个 DC 都能解析”仍不单独证明转发器已复制到两台。

我的回答（命令/GUI、结果、结论）：

1. Resolve-DnsName -Name MFNET-CORE01.mf.net -Server 127.0.0.1 PS C:\Users\Administrator> Resolve-DnsName -Name MFNET-CORE01.mf.net -Server 127.0.0.1

Name Type TTL Section IPAddress

MFNET-CORE01.mf.net A 3565 Answer 192.168.254.15 2. 在 dnsmgmt.msc 中查看条件转发器。

因为“能解析”是结果，“有条件转发器”是配置。结果对，不代表配置在本地。 要证明条件转发器已复制到两台，必须分别在两台 DC 上、显式查本机 DNS、清缓存后，确认 mf.net 的条件转发器区域存在。

复习提示：要证明“配置复制到两台”，重点是分别查询两台 DC 的条件转发器区域（Get-DnsServerZone -ComputerName <DC> -Name mf.net 或 DNS 管理器逐台查看）；清缓存可辅助排除旧解析结果，但不是证明配置存在的必要步骤。贴出的 A 记录只来自其中一次查询，不能写成两台 DC 均已实测。

Q4｜林信任对象与实际可用性（开卷·VM 可选只读）#

分别在 qy.net 和 mf.net 查询对方信任的 Name、Direction、ForestTransitive、SelectiveAuthentication。再说明三层验收：对象存在、信任验证通过、普通用户访问测试资源成功。每一层还不能证明下一层的什么？如果没有 VM 输出，请不要写“已验证”。

我的回答（命令、结果、证据边界）：

**参考解法（PowerShell／命令行）：**分别在两林的 DC 或已加入对应林、装有 RSAT 的管理机执行；不要把其中一侧的查询冒充两侧验证。

1
# QYNET 侧：查 mf.net
2
Get-ADTrust -Identity 'mf.net' |
3
    Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication
4

5
# MFNET 侧：查 qy.net
6
Get-ADTrust -Identity 'qy.net' |
7
    Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication

**GUI：**两边分别打开 domain.msc（Active Directory 域和信任关系）→ 右击林根域 → 属性 →“信任”选项卡；查看对应信任的方向与身份验证范围。选中信任 → 属性 →“验证”，按向导分别验证出站/入站方向；操作需要相应权限，但本题只需写步骤，不要为做题更改信任。

**三层证据：**① Get-ADTrust 查到对象，只说明本侧目录中有信任配置；②“验证”通过，说明相应方向的信任机密/安全通道可用，不说明目标资源授权；③ 用 MF 普通测试账号访问 QY 成员服务器测试共享成功，才说明该用户在这条路径上的认证与授权都通过。当前没有本题的双侧实时 VM 输出，未验证。

你之前从 MFNET 贴出的 Get-ADTrust -Identity 'qy.net' 曾显示 BiDirectional、ForestTransitive=True、SelectiveAuthentication=False；这是历史输出，不代替今天双侧复核。Get-ADTrust 官方文档

Q5｜单向信任的方向（开卷）#

思想实验：只允许 QYNET 普通用户访问 MFNET 成员服务器上的资源，不允许 MFNET 用户反向访问 QYNET。哪一林是提供资源的“信任方”？画出“账号所在林 → 资源所在林”的箭头；分别从 QYNET 与 MFNET 一侧说明单向信任的方向，并附一条支持你判断的微软官方资料链接。只设计，不修改当前双向信任。

我的回答（含资料链接）：

**参考解法：**账号在 QY，资源在 MF：QYNET 用户 → MFNET 资源。MFNET 是提供资源、信任 QYNET 身份的 trusting forest；从 MFNET 看是 outgoing / 出站信任，从 QYNET 看是 incoming / 入站信任。记忆法：资源方信任账号方；箭头表示用户访问方向，不要拿它推断“出站”的中文直觉。

PowerShell／命令行只读核对：在两林各执行 Get-ADTrust -Identity '对方域名' | Select-Object Name,Direction,ForestTransitive；这是查看当前信任，不会把现有双向信任改成题设的单向信任。

GUI：domain.msc → 各林根域“属性”→“信任”选项卡。若是题设单向设计，MFNET 一侧应在“此域信任的域（出站）”，QYNET 一侧应在“信任此域的域（入站）”。这里只看/设计，不创建或修改。

资料：微软的森林信任方向说明（单向信任中，受信任林的用户可向信任林的资源请求访问；仍需具体 ACL 授权）。

Q6｜SPN 与 Kerberos 票据（开卷）#

测试网站 http://testweb.qy.net 没有按预期使用 Kerberos。请查资料并写出三项只读检查：查询 HTTP/testweb.qy.net 注册到了哪个账号、在相关林中查重复 SPN、在客户端查看服务票据。各项结果能回答什么问题？为什么不能未经核对就用 setspn -A 添加 SPN？不要实际新增或删除 SPN。

我的回答：

**参考解法（只读）：**先在服务所在的 qy.net 林检查精确 SPN，再查该林重复项；如果怀疑两个林都存在同名服务，再分别查两林。-F 是当前或 -T 指定林的范围，不会因为存在林信任就自动遍历两个独立林。

1
# 管理端：查 HTTP/testweb.qy.net 落在哪个对象上
2
setspn -T qy.net -F -Q HTTP/testweb.qy.net
3

4
# 管理端：查 qy.net 林的重复 SPN；必要时在 mf.net 林单独查
5
setspn -T qy.net -F -X
6
setspn -T mf.net -F -X
7

8
# 发起请求的客户端：先访问网站，再看服务票据
9
klist

第一条回答“该名字是否注册、归谁”；第二组回答“每个被查林内有无重复”，不能单凭无重复断定账号正确；klist 回答“当前登录会话是否拿到相应服务票据”，需找 HTTP/testweb.qy.net，不能把 TGT 当服务票据。-A 不做重复性检查，不应盲加；若将来获准新增，先核实服务真实运行账号，再用 setspn -S。本题不执行任何新增/删除。

GUI：dsa.msc →“查看”→“高级功能”→ 找到服务账户/计算机对象 →“属性”→“属性编辑器”→ servicePrincipalName 可看该对象的 SPN；但跨对象/全林查重用 setspn 更合适。客户端可用 klist 查看当前票据；Windows GUI 没有同样直接、完整的票据清单入口。参考：setspn 官方文档。

Q7｜选择性身份验证（开卷）#

当前 SelectiveAuthentication=False。如果未来在实验中改成选择性身份验证，跨林用户访问 QYNET 某台成员机，除了共享与 NTFS 权限，还需要给什么权限？这个权限应加到哪个 AD 对象？请找到一条微软官方说明，并用一句话解释“信任允许认证”和“资源 ACL 允许读取”为何仍是不同环节。不要真的修改信任。

我的回答（含资料链接）：

参考解法：在 QYNET 的目标成员服务器对应的 AD 计算机对象上，给 MFNET 的测试用户或其安全组授予 Allowed to Authenticate／允许进行身份验证。这解决“能否向这台计算机认证”；目标共享权限与 NTFS ACL 仍分别决定“能否读文件”。当前 SelectiveAuthentication=False，因此这是未来改为选择性身份验证时的步骤，不要现在修改。

**PowerShell（只读定位）：**在 QY 管理端运行 Get-ADComputer -Identity '<QY成员服务器名>' | Select-Object Name,DistinguishedName；Get-ADTrust -Identity 'mf.net' | Select-Object SelectiveAuthentication。本题不提供容易误改复杂 DACL 的写入脚本。

**GUI：**QY 管理端打开 dsa.msc →“查看”→“高级功能”→ 目标计算机对象“属性”→“安全”→ 添加 MF 测试安全组 → 高级权限中允许“Allowed to Authenticate”；之后还需在目标成员机上核对共享与 NTFS 权限。资料：微软关于选择性身份验证及该权限的说明；这是 Microsoft Q&A 的操作答复，实际改动前还应按环境复核。

Q8｜账户锁定：从日志找来源（开卷·VM 可选只读）#

写出在 DC 上查询最近 20 条 4740 的 PowerShell 命令；事件里哪个字段有助于找锁定来源机器？如果当天没有 4740，如何如实记录？顺便说说 4771 和 4776 分别属于哪类认证，以及为什么看到 4776 不一定代表失败。不要为了制造日志而故意输错密码。

我的回答（若实测，附关键输出）：

**参考解法（PowerShell）：**在账号所属域的 DC 上查 Security 日志（有多个 DC 时应考虑其他 DC）。

1
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20 |
2
    Select-Object TimeCreated,Id,Message

GUI：eventvwr.msc →“Windows 日志”→“安全”→“筛选当前日志”→事件 ID 4740，打开事件看 Caller Computer Name／调用方计算机名。如果今天没有，记录“在所查 DC、所选时间窗内未查到 4740”，而不是“从未发生过锁定”；还要确认审计配置、日志保留和其他 DC。

4771 是 Kerberos 预认证失败；4776 是 NTLM 凭据验证尝试，可能成功也可能失败，需看成功/失败及状态码，不能只凭 ID 说密码错误。资料：4740 字段、4776 成败判断。本题未做 VM 实测。

Q9｜跨林时间偏差（开卷·VM 可选只读）#

从 QYNET-CORE01 对 MFNET-CORE01 测时间偏差，而不是只比较 QYNET 两台 DC。写出命令和你会如何读结果；再写出各自查看时间源、状态的命令。若远端不响应，为什么不能马上说“两个林时间不同步”？不改时间配置。

我的回答（若实测，标明运行机器与目标）：

参考解法：在 QYNET-CORE01 上对 MFNET-CORE01 取 5 个样本；/dataonly 便于读偏差秒数，正负号不如绝对值、稳定性和误差提示重要。

1
# QYNET-CORE01 上执行；只读，不会强制同步
2
w32tm /stripchart /computer:MFNET-CORE01.mf.net /samples:5 /dataonly
3
w32tm /query /source
4
w32tm /query /status
5

6
# MFNET-CORE01 上另执行，查 MF 这一侧的时间源和状态
7
w32tm /query /source
8
w32tm /query /status

**GUI：**两台 DC 各打开“日期和时间”核对当前时间、时区；services.msc 看 Windows Time 服务是否运行；事件查看器看“System”中时间服务相关事件。GUI 可辅助，但跨主机偏差仍推荐 w32tm /stripchart。

若目标不响应，只说明这次 NTP 测量没有成功，可能是名字解析、网络/UDP 123、防火墙或对端 NTP 服务不响应；不能直接断言两个林时间不同步。资料：Windows Time 工具说明。本题未实测。

Q10｜误删用户与备份验证（开卷）#

一个普通测试用户被误删，其他 DC 和业务仍正常。先确认 AD 回收站是否启用，再定位删除对象；写出这两个只读查询，以及在确认唯一 GUID 后可采用的恢复命令（写出但不要执行）。回收站恢复的组成员关系通常如何？为什么“wbadmin 显示备份成功”仍不等于“已证实可恢复”？

我的回答：

**参考解法（只读查询）：**在被删用户所属域的管理端，先看功能对象的 EnabledScopes，再按名称/账号线索筛选已删除对象、核对 ObjectGUID 与 LastKnownParent。不要把查到 Recycle Bin Feature 对象本身当成“已启用”。

1
Get-ADOptionalFeature -Identity 'Recycle Bin Feature' |
2
    Select-Object Name,EnabledScopes
3

4
Get-ADObject -IncludeDeletedObjects `
5
    -Filter 'isDeleted -eq $true -and Name -like "*测试用户*"' `
6
    -Properties ObjectGUID,LastKnownParent,WhenChanged |
7
    Select-Object Name,ObjectGUID,LastKnownParent,WhenChanged
8

9
# 仅示意：审批并确认唯一 GUID 后才可运行；本题禁止执行
10
Restore-ADObject -Identity '<已确认的唯一 ObjectGUID>'

GUI：dsac.exe（Active Directory 管理中心）→ 查是否有“已删除的对象”容器 → 找到该用户并核对属性；真正恢复时选择“还原”或“还原到”。本题只查看，不点恢复。

**重要纠错：**若删除发生在回收站开启之后、对象仍处可恢复期，微软说明恢复用户会带回删除前的组成员关系与相应目录链接；不是“组关系一律丢失”。恢复后仍要核对当前 ACL、跨域复制、已有登录令牌。wbadmin 报“备份成功”仅证明备份作业完成，没证明备份可读、包含所需时间点/组件或演练恢复成功。AD 回收站官方文档。

Q11｜闭卷压轴：复制错误 1722#

QYNET-CORE02 从 QYNET-CORE01 入站复制失败，错误 1722。写出查看复制摘要与 CORE02 入站详情的命令，指出应从哪台向哪台查 DNS 与连接。TCP 135 测试成功后，你仍会保留哪项怀疑？最后说一句：为什么这时不该直接 repadmin /syncall /AdeP？

我的回答：

参考解法：CORE02 是入站复制的目标，CORE01 是来源，因此首先从 CORE02 → CORE01 检查名字解析、地址与 RPC 连通性；也要看 CORE01 服务/防火墙/事件日志。

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

4
# 在 CORE02 上针对来源 CORE01 检查
5
Resolve-DnsName QYNET-CORE01.qy.net
6
Test-NetConnection QYNET-CORE01.qy.net -Port 135

**GUI：**在 CORE02 打开 dssite.msc（AD 站点和服务）看 NTDS Settings/连接对象，在两台 DC 打开事件查看器看 Directory Service、DNS Server、System；防火墙高级安全界面核对相关入站规则。GUI 很难代替 repadmin 的复制摘要与逐邻居错误码。

TCP 135 成功只证明 RPC Endpoint Mapper 可达，不证明映射到的动态 RPC 端口也可达。1722 也可能有 DNS、服务、路由等原因。尚未定位原因时直接 /syncall /AdeP 既不能修复断开的 RPC，也可能使多站点链路承压。微软 1722 排障文档。

Q12｜开卷压轴：真正验收跨林访问#

信任向导显示成功，两边 nltest /dsgetdc 也能定位对方 DC，但一个 MFNET 普通测试用户仍无法读取 QYNET 成员机上的测试共享。请写一份按顺序排查的短工单：涵盖 DNS/时间、信任方向与验证、客户端实际使用的 SMB 凭据与 Kerberos 票据、MF 全局组 → QY 域本地组、共享与 NTFS ACL、复测及回退。每一步标明在哪台机器做，并引用一条你查到的微软官方资料。不要把使用 qy\Administrator 访问 NETLOGON 当成成功验收。

我的回答（可分步骤）：

参考工单（只读诊断；修复前另行确认）：

1. **MF 测试客户端、QY 目标成员机及两侧 DC：**确认目标主机 A 记录和对方林的 DC SRV 记录能通过各自本机 DNS 解析；Resolve-DnsName <目标主机>、nltest /dsgetdc:qy.net /force。在 DNS 管理器核对两侧条件转发器。DC 定位成功只证明发现 DC，不证明信任/ACL。
2. QYNET-CORE01 与 MFNET-CORE01：w32tm /query /source、w32tm /query /status；可在 QY 侧用 w32tm /stripchart /computer:MFNET-CORE01.mf.net /samples:5 /dataonly 看偏差。GUI 看日期时间、Windows Time 服务；不随手重配 NTP。
3. **两林管理端：**分别 Get-ADTrust -Identity '对方域名' | Select Name,Direction,ForestTransitive,SelectiveAuthentication；domain.msc 的“信任”页核对方向，再用“验证”分别验证所需方向。对象存在、验证通过、资源访问成功是三个不同层次。
4. **MF 普通测试客户端：**先 whoami 确认当前身份；Get-SmbConnection -ServerName '<QY成员服务器名>' | Select ServerName,ShareName,UserName,Credential 检查是否误用了 qy\Administrator 或旧凭据；访问测试共享后 klist 看目标 cifs/<QY成员服务器名> 票据。GUI 可在“凭据管理器”检查保存的目标凭据、在“此电脑/映射网络驱动器”核对连接用户。不要未经许可清空他人的凭据或票据。
5. **MF/QY 两侧目录管理端：**MF 测试用户应属于 MF Global Security 组；此组应加入 QY Domain Local Security 组。Get-ADPrincipalGroupMembership -Identity '<MF测试用户>' 在 MF 查本域归属；在 QY 侧查资源组 Get-ADGroup -Identity '<QY资源组>' -Properties Members | Select-Object -ExpandProperty Members。跨林成员可能显示为 Foreign Security Principal，不能只凭显示名判断。GUI 用 dsa.msc 查看两侧组的“成员/隶属于”。若选择性身份验证启用，还需 QY 目标计算机对象上的 Allowed to Authenticate。
6. **QY 目标成员机：**共享“属性→共享→高级共享→权限”和文件夹“属性→安全”分别检查 QY 资源组的读取权限；PowerShell 可用 Get-SmbShareAccess -Name '<测试共享名>' 与 Get-Acl '<本地测试目录>' 辅助。两层权限都需要放行，显式拒绝和继承也要看。
7. **复测与回退：**在 MF 普通测试用户的新会话中，不输入 QY 管理员凭据，重新访问 \\<QY成员服务器>\<测试共享>，记录成功/失败、实际 SMB 凭据与相关票据。若调整了组，先等待复制并重新登录取得新令牌；仅删除临时测试 ACL/组成员/测试共享等本次获批创建的变更，按变更记录回退，不回滚既有双向信任。

参考：微软安全组范围与可嵌套关系（MF 全局组可加入信任域的域本地组）；森林信任与资源访问说明。本题没有做新的 VM 验证。

复习自查#

• 我没有把“DNS 能解析”“信任对象存在”“普通用户有资源权限”当成同一件事。
• 实测输出只写真正运行过的；资料链接说明支持哪一步。
• 不会的地方写了自己会先查什么。

**本次 VM 实测记录：**Q3 保留了一次 A 记录查询输出；Q4～Q12 没有新的 VM 实测。 **下次优先亲手做：**Q4 双侧信任查询/GUI 验证、Q9 跨林时间抽样、Q12 非管理员共享验收。