Windows AD PowerShell(十六):跨域与跨林信任
这是 Windows AD PowerShell 学习记录的第十六节。前面已经分别学过 DNS 与 SPN、时间同步 和 组与成员;跨林故障正是这些知识点一起出现的场景。
**数据来源说明:**文中标明“历史实测”的结果来自我此前在聊天里贴出的 VM PowerShell 输出,不是 2026-10-08 重新连接 VM 的结果。其余只读命令提供可直接照着检查的写法,不虚构运行结果。建立/修改信任、条件转发器、组和 ACL 都是变更操作,本节只讲步骤或预演,不在 VM 上执行。
十六、跨域与跨林信任
16.1 先分清:子域与另一片森林
| 实验对象 | 所在林 | 与 qy.net 的关系 |
|---|---|---|
qy.net | qy.net | 林根域;QYNET-CORE01、CORE02 是其中的 DC |
suba.qy.net | qy.net | 同一林中的子域;同林域之间默认有双向可传递信任 |
mf.net | mf.net | 独立林;MFNET-CORE01 是其 DC,需要单独建立林信任 |
“跨域”只说明账号域与资源域不同,不一定跨林;qy.net → suba.qy.net 是同林跨域,qy.net → mf.net 才是跨林。林信任不合并用户数据库、GPO 或管理员权限;它只提供跨林身份验证路径,资源是否能访问还要看授权。
先确认自己当前连接的是哪一林:
# 分别在 QYNET / MFNET 的管理环境中执行Get-ADDomain | Select-Object DNSRoot,NetBIOSName,Forest,DomainModeGet-ADForest | Select-Object Name,RootDomain,ForestMode
# 历史实测:QYNET 一侧的关键值# DNSRoot=qy.net;NetBIOSName=qy;Forest=qy.net;DomainMode=Windows2016Domain# Name=qy.net;RootDomain=qy.net;ForestMode=Windows2016Forest
# 历史实测:MFNET 一侧的关键值# DNSRoot=mf.net;NetBIOSName=MF;Forest=mf.net;DomainMode=Windows2016Domain# Name=mf.net;RootDomain=mf.net;ForestMode=Windows2016ForestGUI:“Active Directory 域和信任关系”中看林根域与“信任”选项卡;“Active Directory 用户和计算机”中看到一个域节点,不代表它就是另一片林。具体林名仍以 Get-ADForest 或 AD 域和信任关系为准。
16.2 第一关:两边的 DNS 都要认识对方
建立信任前,先从各自的本机 DNS解析对方的 DC A 记录与 DC 定位 SRV 记录。直接向对方 DNS 服务器查询成功,只能说明“对方 DNS 有记录”,不能说明本地 DNS 知道如何转发。
# 在 QYNET-CORE01 上:直接问 MFNET DNSResolve-DnsName MFNET-CORE01.mf.net -Type A -Server 192.168.254.15Resolve-DnsName _ldap._tcp.dc._msdcs.mf.net -Type SRV -Server 192.168.254.15
# 历史实测:A -> 192.168.254.15;SRV -> MFNET-CORE01.mf.net:389
# 再问 QYNET-CORE01 自己使用的 DNSResolve-DnsName MFNET-CORE01.mf.net -Type A -Server 127.0.0.1Resolve-DnsName _ldap._tcp.dc._msdcs.mf.net -Type SRV -Server 127.0.0.1
# 历史实测:配置转发器之前,本机 A 查询曾报 DNS_ERROR_RCODE_NAME_ERROR;# 配好条件转发器后,本机 A 与 SRV 查询均成功。MFNET 一侧也要对称检查 QYNET-CORE01.qy.net 和 _ldap._tcp.dc._msdcs.qy.net。此前在 MFNET-CORE01 的历史实测中,本机 DNS 解析到了 QYNET-CORE01 192.168.254.10、QYNET-CORE02 192.168.254.11,SRV 记录指向两台 DC 的 389 端口。
**GUI:**两侧分别运行 dnsmgmt.msc →“条件转发器”:QYNET DNS 的 mf.net 指向 192.168.254.15;MFNET DNS 的 qy.net 指向 192.168.254.10、192.168.254.11。如需要在多台 DNS/DC 间复制,还应检查区域属性中的 AD 存储与复制范围,并在每台 DC 上分别核对实际配置。
PowerShell 查询条件转发器区域的正确 cmdlet 是 Get-DnsServerZone:
# 在 QYNET 管理端分别点名查询 CORE01、CORE02;本节未实测Get-DnsServerZone -ComputerName QYNET-CORE01 -Name 'mf.net' | Select-Object ZoneName,ZoneType,MasterServers,ReplicationScope
Get-DnsServerZone -ComputerName QYNET-CORE02 -Name 'mf.net' | Select-Object ZoneName,ZoneType,MasterServers,ReplicationScope
# 在 MFNET 管理端查询反向的条件转发器;本节未实测Get-DnsServerZone -ComputerName MFNET-CORE01 -Name 'qy.net' | Select-Object ZoneName,ZoneType,MasterServers,ReplicationScope⚠️ 命令易错点:
Get-DnsServerConditionalForwarderZone不是现成 cmdlet。我之前敲它得到“无法识别为 cmdlet”是命令名问题,不是 DNS 服务异常。条件转发器保存在 DNS 的 forwarder zone 中,使用Get-DnsServerZone查看。若Get-DnsServerZone也不存在,先检查 DNS Server 管理模块/RSAT,或直接用 GUI。
如果是新环境而且确实需要创建,先确认本机尚无同名区域、范围及对端地址;以下只是预演,当前实验林已经配好,不要重复执行:
# QYNET 侧示意:仅预演,不改动Add-DnsServerConditionalForwarderZone -Name 'mf.net' ` -MasterServers 192.168.254.15 -ReplicationScope Domain -WhatIf
# MFNET 侧示意:仅预演,不改动Add-DnsServerConditionalForwarderZone -Name 'qy.net' ` -MasterServers 192.168.254.10,192.168.254.11 -ReplicationScope Domain -WhatIf
# -WhatIf 只显示预演信息;本节未在 VM 执行Domain 是在当前域中的 DNS/DC 间复制,不等于自动覆盖另一个林或子域;多域环境应按实际 DNS 布局规划复制范围。即便两台 DC 都能解析,也可能是缓存、普通转发器或其他路径的结果,不能单凭解析成功证明条件转发器已复制;要逐台查区域配置。
16.3 第二关:能不能找到对方的 DC?
# QYNET 侧找 MFNET 的 DCnltest /dsgetdc:mf.net /force
# 历史实测关键结果:\\MFNET-CORE01.mf.net,192.168.254.15,命令成功
# MFNET 侧找 QYNET 的 DCnltest /dsgetdc:qy.net /force
# 历史实测关键结果:\\QYNET-CORE01.qy.net,192.168.254.10,命令成功nltest /dsgetdc 说明 DC Locator 成功找到目标 DC;不证明信任机密可用,也不证明某个普通用户有共享权限。如果这一步失败,先回头查本机 DNS、SRV、IP/路由及防火墙,不急着改信任。
**GUI:**DNS 管理器中查看对方域的转发器,以及用 DNS 管理器的查询检查 DC 的 A/SRV 记录。具体 DC 定位结果还是 nltest 更直接。
16.4 第三关:信任对象、方向与验证
Get-ADTrust 用于查询现有信任;它本身不创建林信任。分别在两边查询,不要只看到一侧的对象就认定全链路正常。
# 在 QYNET 环境中Get-ADTrust -Identity 'mf.net' | Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication,TrustType
# 在 MFNET 环境中Get-ADTrust -Identity 'qy.net' | Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication,TrustType
# 历史实测:MFNET 一侧曾返回# Name=qy.net;Direction=BiDirectional;ForestTransitive=True;# SelectiveAuthentication=False;TrustType=Uplevel| 字段 | 怎么读 |
|---|---|
Direction | 相对于当前查询的域的信任方向;BiDirectional 是双向 |
ForestTransitive | True 表示林信任的可传递属性;与简单外部信任不同 |
SelectiveAuthentication | False 表示当前未启用选择性身份验证;仍然需要资源 ACL |
TrustType=Uplevel | Windows AD 域类型;不能只凭它判定是不是林信任,还要看 ForestTransitive |
**单向方向题:**若只让 QYNET 普通用户访问 MFNET 资源,账号访问方向是 QYNET 用户 → MFNET 资源。MFNET 是资源方,也是信任 QYNET 身份的一方:从 MFNET 看是出站信任,从 QYNET 看是入站信任。双向信任是两个方向都允许走认证路径,不是两边的用户自动获得对方文件权限。
**GUI 创建/查看:**在两林根域的管理端运行 domain.msc → 右击域“属性”→“信任”→“新建信任”。若目标是 qy.net 与 mf.net 两片独立 AD 森林,选“林信任”,而不是“外部信任”;再按实验目标选择单向/双向,并确认身份验证范围。向导可选择只创建当前侧或同时创建两侧,取决于你是否具备双方相应管理凭据;完成后在两侧“信任”页逐一查看。当前实验已建双向林信任,本节不重复创建。
⚠️ 微软的
netdom trust文档明确指出:netdom trust不能用来创建两个 AD DS 林之间的林信任。建林信任优先使用“Active Directory 域和信任关系”向导;netdom trust可以用于验证既有信任。不要把netdom /add当成这两片林的通用建林信任命令。
只读/验证操作与“对象存在”也不是一回事:
# 在有相应权限的管理端验证现有信任;不使用 /add、/remove、/resetnetdom trust qy.net /domain:mf.net /verify
# 本节未执行;执行后需要核对返回状态,必要时再从另一侧验证GUI 验证:domain.msc → 域“属性”→“信任”→ 选中 mf.net/qy.net →“属性”→“验证”;对需要的方向分别验证。验证可能要求对端凭据;不要把密码写进命令行或笔记。
16.5 第四关:普通用户能否访问目标资源?
这一步才是真正的业务验收。我之前在 MFNET-CORE01 打开 \\QYNET-CORE01\netlogon,弹出凭据窗口后输入 qy\Administrator,访问成功;随后看到:
# 历史实测:在 MFNET-CORE01 上运行Get-SmbConnection -ServerName QYNET-CORE01 | Select-Object ServerName,ShareName,UserName,Credential
ServerName ShareName UserName Credential---------- --------- -------- ----------QYNET-CORE01 IPC$ MF\Administrator qy\AdministratorQYNET-CORE01 netlogon MF\Administrator qy\Administrator这里的 UserName 是本机会话的用户,Credential 是连接时使用的凭据。**这次访问使用了 QY 的管理员凭据,不能证明 MF 普通账号通过信任访问 QY 资源。**而且 DC 的 NETLOGON 不适合作为普通用户权限验收的测试共享。
更合适的实验是:在 MF 准备普通测试用户和 Global Security 组,在 QY 的域本地 Security 组中加入该 MF 全局组,再把 QY 域本地组授予 QY 成员服务器上专用测试共享的共享权限和 NTFS 权限。测试用户在自己的会话里访问共享,不输入 qy\Administrator。
# MF 测试客户端:确认当前会话和 SMB 凭据whoamiGet-SmbConnection -ServerName '<QY成员服务器名>' | Select-Object ServerName,ShareName,UserName,Credential
# 访问测试共享后,检查是否取得 cifs/目标主机 的服务票据klist
# QY 目标成员服务器:查询测试共享权限和本地文件 ACLGet-SmbShareAccess -Name '<测试共享名>'Get-Acl '<测试目录的本地路径>' | Select-Object -ExpandProperty Access
# 本节没有创建测试账号、组、共享,也没有做本轮实测GUI:dsa.msc 分别看 MF 全局组、QY 域本地组及其成员;QY 成员机上打开共享“属性→共享→高级共享→权限”和文件夹“属性→安全”,两层都要核对。MF 客户端的“凭据管理器”可查看是否保存了其他账号的 SMB 凭据。组关系刚改变时,等复制并让测试用户重新登录,再复测;仅 klist purge 不一定更新已有登录令牌或旧 SMB 连接。
如果日后启用选择性身份验证,还要在 QY 目标成员服务器的 AD 计算机对象上,给 MF 测试用户/安全组授予“Allowed to Authenticate/允许进行身份验证”;这是认证门槛,与共享和 NTFS ACL 是不同的检查点。当前历史查询 SelectiveAuthentication=False,本节不建议改动它。
16.6 出问题时按哪条顺序查?
| 现象 | 先看哪里 | 不要直接推断 |
|---|---|---|
| 直接问对方 DNS 成功,本机 DNS 查不到 | 本侧条件转发器与本机 DNS 缓存 | 对方 DC 已坏 |
A 记录能解析,nltest /dsgetdc 失败 | SRV 记录、DC 地址/端口、路由 | 信任对象一定坏了 |
| 两侧能找到 DC,信任验证失败 | 两侧信任方向/机密、时间、网络与事件日志 | 有 DNS 就必然能认证 |
| 信任验证通过,普通用户仍被拒绝 | 当前 SMB 凭据、选择性身份验证、组与共享/NTFS ACL | 双向信任自动给了读取权限 |
| 用 QY 管理员凭据能访问 | 先换 MF 普通测试身份重新验收 | MF 普通用户已跨林成功 |
时间偏差可从 QYNET-CORE01 对 MFNET-CORE01 作只读抽样,不要只比较 QYNET 两台 DC:
# QYNET-CORE01 上,目标为 MFNET-CORE01w32tm /stripchart /computer:MFNET-CORE01.mf.net /samples:5 /dataonly
# 两边各自查看本机时间源/状态w32tm /query /sourcew32tm /query /status
# 本节未实测;远端不响应也不能直接断定时钟不同步跨林防火墙问题也不能只用 Ping 或 TCP 135 下结论。TCP 135 是 RPC Endpoint Mapper,后续还可能转到动态 RPC 端口;Kerberos、LDAP、DNS、SMB 等端口也需按具体测试路径评估。不建议为了“让信任通”直接关掉两侧防火墙。
16.7 自己复习时记住这四句话
- 同林子域 ≠ 独立林。
suba.qy.net与mf.net是两类关系。 - **DNS 能解析 ≠ 信任能用。**查询配置、定位 DC、验证信任是不同证据。
- **信任能用 ≠ 用户有资源权限。**目标侧组和 ACL 仍要授权。
- **管理员凭据能访问 ≠ 普通跨林账号验收成功。**看实际 SMB 凭据与票据。
想用题目逐步练习,可以接着看 Windows AD Practice Day7;其中 Q4~Q12 附有命令行和 GUI 两种参考解法。
参考资料
- Microsoft Learn:Get-ADTrust
- Microsoft Learn:DNS 条件转发器与转发机制
- Microsoft Learn:Get-DnsServerZone
- Microsoft Learn:Add-DnsServerConditionalForwarderZone
- Microsoft Learn:netdom trust
- Microsoft Learn:AD 安全组范围
- Microsoft Learn:Windows Time 工具
支持与分享
如果这篇文章对你有帮助,欢迎分享给更多人或打赏支持!













