ad域控间复制因tcp端口被封堵导致失败，典型表现为repadmin报1722/1726/1257错误、事件id 1925/2087/1311，需逐端口验证389/445/135等连通性并分层排查防火墙与网络设备策略。
ad域控间复制报错，若根因是tcp端口被封堵，会直接中断rpc、ldap、kerberos等关键通信链路，导致复制失败、服务不可用、客户端无法定位dc等连锁问题。排查需聚焦“端口连通性验证→协议层映射→防火墙与中间设备确认”三层逻辑，避免仅查dns或服务状态而忽略网络策略。
确认AD复制失败的具体错误表现
先明确是否属于端口阻断类故障，典型信号包括：
- repadmin /showrepl 显示“RPC服务器不可用”“拒绝访问”“连接超时”，而非“目标主体名称不正确”或“访问被拒绝（安全上下文）”
- dcdiag /test:replications 报错状态码为 1722（RPC服务器不可用）、1726（RPC服务器太忙）、1257（远程过程调用失败）
- 事件查看器中“Directory Service”日志出现事件ID 1925（无法联系源DC）、2087（复制连接失败）、1311（无法建立到源DC的连接）
- 使用 nltest /dsgetdc:domain.com 或 nslookup _ldap._tcp.dc._msdcs.domain.com 成功，但 repadmin /bind 或 test-netconnection -port 389 失败
逐端口验证域控间TCP连通性
AD复制依赖多个TCP端口，必须逐一实测。在目标DC上执行（以源DC FQDN 或 IP 为目标）：
-
TCP 389（LDAP）：
Test-NetConnection dc01.contoso.com -Port 389 -InformationLevel Detailed—— 验证基础目录查询能力 -
TCP 445（SMB/LSA）：
Test-NetConnection dc01.contoso.com -Port 445—— 复制元数据、SYSVOL同步必需 -
TCP 135（RPC Endpoint Mapper）：
Test-NetConnection dc01.contoso.com -Port 135—— 动态RPC端口协商起点 -
TCP 636（LDAPS）（如启用SSL）：
Test-NetConnection dc01.contoso.com -Port 636 -
TCP 3268/3269（GC/LDAPS GC）（跨域场景）：
Test-NetConnection dc01.contoso.com -Port 3268
注意：若某端口返回 False 或 TimedOut，即表明该端口被封堵；若返回 True 但复制仍失败，需继续检查UDP端口（如88、123）或服务依赖项。
定位封堵位置：从本机防火墙到网络设备
端口不通≠一定是网络设备拦截，需分层排除：
-
本机Windows防火墙：在源DC和目标DC上运行
Get-NetFirewallProfile | fl Name,Enabled，确认域配置文件未误启“阻止入站连接”；检查入站规则是否放行 Active Directory Domain Controller、File and Printer Sharing、Remote Event Log Management 等预设规则组 - 第三方安全软件：检查终端防护平台（如Symantec、CrowdStrike）是否启用“网络微隔离”或“横向移动防护”策略，临时禁用测试
-
中间网络设备：使用
tracert -d dc01.contoso.com查看路径跳点，在疑似跳点（如核心交换机、防火墙、负载均衡器）抓包或登录CLI检查ACL策略，重点关注 deny tcp any any eq 135,389,445 类规则 - 云环境特殊限制：Azure VM NSG、AWS Security Group、华为云安全组默认拒绝所有入向，需显式添加允许规则（源/目标IP+端口+协议）
验证修复后复制状态
端口恢复后，不要仅依赖自动同步，应主动触发并验证：
- 手动强制复制：
repadmin /replicate dc02.contoso.com dc01.contoso.com "DC=contoso,DC=com" - 检查结果：
repadmin /showrepl dc02.contoso.com确认“Last attempt”时间更新且状态为“succeeded” - 同步SYSVOL：
dfsrmig /getglobalstate和gpupdate /force后检查组策略是否生效 - 交叉验证：
dcdiag /test:connectivity /test:replications双重确认
端口封堵类问题往往隐蔽但路径清晰，关键是把“能解析”和“能通信”区分开，用端口级探测代替服务级判断，就能快速定位策略卡点。
