故障背景与现象
某中型制造企业运行基于Windows Server 2019 Active Directory (AD) 的域环境，拥有约500台终端和核心业务系统依赖域认证。近期，IT支持团队接到多起报告，主要现象包括：
- 部分域成员计算机在登录时出现长时间卡顿，随后提示“无法联系域控制器”。
- 应用程序调用LDAP接口查询用户属性时返回“拒绝访问”或超时错误。
- Exchange Server 2019 与AD集成组件出现同步延迟，邮件收发异常。
初步排查网络连通性（Ping、Telnet端口389/636）均正常，防火墙策略无变更，且重启相关服务无效。这表明故障可能深层次存在于身份验证或目录服务的安全机制中。
深入排查与根因定位
1. 检查事件查看器日志
在故障最频繁的域控制器（DC）上打开“事件查看器”，导航至 应用程序和服务日志 -> Microsoft -> Windows -> CertificateServicesClient-Lifecycle-System 和 Directory Service。发现大量来源为 ADAuth 的事件ID 4096和4097，提示“证书吊销列表(CRL)检查失败”或“信任链验证错误”。
2. 分析证书状态
使用PowerShell命令查看域内CA服务器的证书状态：
Get-Certificate -Template DomainController -Url ldap://进一步检查内置CA（Microsoft Root CA）的有效期。发现该CA用于签发域控制器身份验证证书的签名证书即将过期，且由于内部PKI架构配置疏忽，未及时续期或更新CRL分发表。当证书过期后，依赖LDAPS（端口636）的安全通信链路被阻断，Kerberos TGT请求中的证书部分无法通过信任链验证，导致LDAP查询被拒绝。
3. 确认影响范围
通过 `Test-ComputerSecureChannel` 命令测试域成员与DC的信任关系，发现部分机器返回False，证实证书过期已破坏安全通道。
解决方案实施步骤
为解决此问题，需重新颁发并部署有效的身份验证证书。以下是标准化操作流程：
第一步：在域控制器上申请新证书
在每一台受影响的域控制器上，以管理员身份运行PowerShell，执行以下命令获取新的计算机证书：
由于AD域控通常使用内置的“Domain Controller”模板，我们需要确保证书模板有效且未被吊销。
若CA服务正常运行但证书过期，最简单的办法是重置CA并重新发布，或者更推荐的做法是：直接在DC上使用 certlm.msc 本地组策略对象编辑器，触发证书自动注册更新。
具体操作：
- 按 Win + R，输入
gpupdate /force强制刷新组策略。 - 打开
certlm.msc（本地计算机证书管理）。 - 进入“个人”->“证书”，检查是否存在由企业CA签发的、有效期正常的“智能卡登录”或“服务器身份验证”用途的证书。
- 如果不存在，手动通过
certreq工具或MMC证书控制台向企业CA请求新证书，模板选择 Domain Controller。
第二步：确保证书绑定正确
新证书颁发后，需确保IIS和LDAP服务使用该证书：
- 打开
inetmgr(IIS管理器)。 - 点击服务器节点，双击“服务器证书”。
- 将新的有效证书绑定到默认网站和必要的内部站点，确保HTTPS监听端口。
- 对于LDAP，Windows通常会自动关联当前有效的域控身份验证证书。可通过
netsh http show sslcert查看绑定情况。
第三步：更新CRL分发点（如有必要）
如果故障是由CRL过期引起，需在CA服务器上重新生成CRL文件，并确保所有域控和客户端能访问新的CRL分发URL（通常是一个HTTP或LDAP地址）。在AD中，这涉及更新组策略中的“证书路径验证设置”。
第四步：重启关键服务
在每域控制器上执行：
Restart-Service NlaSvc（网络位置感知）Restart-Service Kdc（Kerberos密钥分发中心）Restart-Service Netlogon（NETLOGON服务）
随后在客户端机器上再次执行 gpupdate /force 并重启计算机，以重新建立与DC的安全通道。
预防与维护建议
为避免此类“静默”故障再次发生，建议采取以下措施：
- 监控证书有效期： 使用SCCM、SolarWinds或自定义PowerShell脚本定期扫描域内所有服务器的证书到期时间，提前30天告警。
- 自动化续期： 启用证书自动注册策略（Auto-Enrollment），确保证书在到期前自动更新。
- 规范PKI架构： 对于大型企业，建议使用独立的Enterprise CA而非仅依赖内置CA，以便更好地控制证书生命周期和撤销列表(CRL)的分发频率。
总结
本次故障的根本原因在于基础设施层的证书管理缺失，导致依赖证书的身份验证协议（Kerberos/LDAPS）失效。通过重新申请有效证书、更新组策略并重启相关服务，业务迅速恢复正常。此案例提醒IT运维人员，除了关注应用层服务外，底层的安全证书生命周期管理同样至关重要，往往是隐形的故障源头。
