核心目标是确保ldap、kerberos、dns同步等关键dc间通信全程加密且身份可信，需严格限定源/目标ip、优先使用kerberos认证、通过gpo集中部署并强制“要求安全”，禁用默认响应规则与预共享密钥，最后通过netsh、wireshark及事件日志验证协商成功与流量加密。
在ad域环境中，配置ipsec策略实现域控制器（dc）之间的加密数据传输，核心目标是确保ldap、kerberos、dns同步等关键通信全程受保护，防止中间人窃听或篡改。这不是简单“开个加密开关”，而是要让两台或多台dc在建立连接前，自动协商密钥、验证身份、加密载荷——整个过程对上层服务完全透明。
明确保护对象：只加密DC间必要流量
域控通信涉及多个端口和协议，但并非全部需要IPSec加密。重点锁定以下三类：
- LDAP/TLS通信（389/636端口）：目录查询与写入，明文风险高
- Kerberos认证（88端口）：票据交换若被截获，可能被重放或解密
- AD复制流量（通常走RPC动态端口，但实际由135+高危端口触发）：FSMO角色同步、SYSVOL复制等
注意：不要对所有端口或所有IP启用IPSec规则，否则可能阻断NetLogon注册、DNS动态更新等基础功能。应严格限定源/目标为各DC的静态IP地址（如192.168.10.10 ↔ 192.168.10.11），协议类型选“任何”或按需指定TCP/UDP。
选择身份验证方式：优先用Kerberos，禁用预共享密钥
域环境天然支持Kerberos，这是最安全、最省维护的身份验证机制：
- 在IPSec策略的“身份验证方法”中，必须选择“使用此计算机的活动目录凭据（Kerberos V5）”
- 确保所有DC时间偏差≤5分钟（Kerberos默认容忍阈值），否则协商直接失败；建议统一指向域内PDC仿真器做NTP源
- 绝对避免使用“预共享密钥”——它无法与AD集成，密钥需手动分发且无法轮换，违背域管理原则
组策略集中部署：统一应用到所有DC计算机
本地安全策略（secpol.msc）仅适用于单机，DC必须通过组策略批量下发，保证策略一致性：
- 打开gpmc.msc → 定位到包含所有DC的OU（如“Domain Controllers”）
- 新建GPO，命名建议含“DC-IPSec-Encrypt-2026Q2”便于追踪
- 编辑策略 → 计算机配置 → 策略 → Windows设置 → 安全设置 → IP安全策略 → 在本地计算机上
- 右键“创建IP安全策略”，勾选“激活默认响应规则”不可勾选（它会强制响应所有未匹配请求，易引发干扰）
- 添加规则时，在“IP筛选器列表”中精确填写每对DC的双向IP范围；在“筛选器操作”中启用“要求安全”并勾选“接受未加密的通信”不勾选（必须强制加密）
验证与排错关键点
策略部署后不能仅看“已启用”，需实测通信是否真正加密且稳定：
- 在任意DC上运行：netsh ipsec static show all 查看策略是否加载成功
- 抓包验证：用Wireshark过滤tcp.port == 389，确认payload为乱码（非明文DN/attributes）
- 检查事件日志：Windows日志 → 安全 → 查找ID为4653（IPSec协商成功）或5010（协商失败）的事件
- 常见失败原因：DC间DNS反向解析失败（导致Kerberos无法定位SPN）、防火墙临时拦截IKE协商（UDP 500/4500）、GPO未刷新（需执行gpupdate /force并重启IPSec服务）
