额外域控制器（ADC）未参与用户认证问题排查咨询

看到你遇到了额外域控制器（ADC）不参与用户认证的问题，既然已经确认了AD复制和DNS配置都正常，那咱们可以从以下几个方向再深入排查：

• 检查AD站点与服务配置
  客户端默认会优先选择同站点的域控制器进行认证，先确认ADC是否被正确分配到对应的站点，且客户端所在子网已关联到该站点。另外，查看站点链接的开销设置，是否存在限制跨站点认证的配置，导致客户端始终优先选择PDC所在站点的控制器。

• 验证DNS SRV记录的优先级与权重
  虽然你提到DNS看起来正常，但可以通过命令检查DC的SRV记录参数：

  nslookup -type=SRV _ldap._tcp.dc._msdcs.你的域名
  

  查看PDC和ADC的Priority（优先级，数值越小越优先）和Weight（权重，数值越大优先级越高），如果PDC的优先级更低或权重更高，客户端会优先选择它；若两者参数一致，理论上会负载均衡，但实际可能受客户端缓存影响。

• 排查客户端的DC定位逻辑
  在客户端执行以下命令，确认它能识别到ADC：

  nltest /dsgetdc:你的域名
  

  同时用echo %logonserver%查看当前登录使用的DC。另外检查客户端的DNS服务器配置，是否同时指向了PDC和ADC，如果只配置了PDC，客户端自然只会向它发起认证请求。

• 全面检查ADC的健康状态
  在ADC上执行dcdiag命令，进行域控制器健康诊断，重点关注是否存在服务异常、AD数据库错误或FSMO角色相关问题（虽然ADC一般不持有FSMO，但需确认它能正常同步角色信息）。同时检查关键服务（Netlogon、Kerberos Key Distribution Center）是否正常运行。

• 查看ADC的认证日志
  打开ADC的事件查看器，定位到Windows日志 -> 安全，筛选事件ID 4624（成功登录）和4625（登录失败），确认是否有客户端的认证请求记录：

  • 如果完全没有记录，说明客户端未尝试连接ADC；
  • 如果有失败记录，可根据事件中的错误代码进一步定位问题（比如权限不足、Kerberos票据问题等）。

• 检查组策略与特殊配置
  确认是否存在组策略强制客户端仅使用指定DC认证，或者在AD站点与服务中是否将ADC标记为“不可用”。另外，若客户端依赖全局编录服务，需确认ADC是否已配置为全局编录服务器（在AD站点与服务中查看DC属性）。

你可以先从这些方向入手排查，若有具体的报错信息或排查结果，补充后能更精准地定位问题~

备注：内容来源于stack exchange，提问作者homayoun shokri