PAYATHON 2026

Go 通过 LDAPS 连接 Active Directory 时为何被重置？

数据小许

结论

Kerberos 通常用于 LDAP 连接建立后的身份验证，例如通过 SASL/GSSAPI 绑定。它一般不是建立 TCP 或 LDAPS/TLS 连接时使用的凭据。因此，排查时可以先检查地址、端口、TLS 握手和服务器证书，再检查 Kerberos 绑定。

现有信息不足以确定连接重置的具体原因。Connection closed/reset by peer 表示连接在建立阶段被关闭或重置，可能与目标地址或端口、网络策略、TLS 配置或服务器端策略有关。如果错误发生在 ldap.DialURL 调用处，代码还没有获得可用的 LDAP 连接对象。

先确认 defer 的行为

defer l.Close() 会在当前函数返回时执行，不会在写到这一行后立即关闭连接。只有 ldap.DialURL 成功返回并执行到 defer 时，关闭操作才会注册。如果 DialURL 返回错误，defer 不会执行。

按传输层逐步排查

1. 核对主机名和端口

确认 xx.xx.x.x 是实际的域控制器地址，并核实 IT 提供的 LDAPS 地址和端口。LDAPS 通常使用 636，LDAP 常使用 389。不要把明文 LDAP 协议发到只接受 TLS 的端口，也不要在未确认服务器配置前假设 389 和 636 可以互换。

在 Linux 上，可以先检查 TCP 端口是否可达：

nc -vz dc.example.com 636

这只能确认 TCP 层是否连通，不能证明 LDAPS 握手成功，也不能验证 LDAP 请求是否有效。

2. 检查 LDAPS 的 TLS 握手

使用与服务器证书对应的 DNS 名称检查 636 端口：

openssl s_client -connect dc.example.com:636 -servername dc.example.com -showcerts

如果通过 IP 连接，而证书签发给域名，证书校验可能因名称不匹配而失败。应优先使用与证书匹配的服务器名称，并确认运行 Go 守护进程的系统信任该证书链。不要关闭证书校验来掩盖问题。

下面的 Go 代码可单独检查 TCP 连接和 TLS 握手。它不执行 LDAP 操作，也不能替代 ldap.DialURL 的完整验证：

package main

import (
	"crypto/tls"
	"fmt"
	"net"
	"time"
)

func checkTLS() error {
	dialer := &net.Dialer{Timeout: 5 * time.Second}
	conn, err := tls.DialWithDialer(dialer, "tcp", "dc.example.com:636", &tls.Config{
		ServerName: "dc.example.com",
	})
	if err != nil {
		return fmt.Errorf("LDAPS TLS handshake failed: %w", err)
	}
	defer conn.Close()
	return nil
}

将示例主机名替换为实际的域控制器名称。如果这一步失败，根据具体错误检查端口、证书、TLS 配置和中间网络设备。如果 TLS 握手成功，但 LDAP 连接仍然失败，再检查 Go LDAP 客户端的连接参数和服务器端日志。

3. 确认 LDAP 与 LDAPS 配置对应

如果 IT 策略要求使用 LDAPS，应配置正确的 LDAPS 地址和端口。如果组织使用 LDAP 389 加 StartTLS，则需要按服务器要求先升级到 TLS。这与直接连接 LDAPS 端口是两种不同的连接方式。具体配置应以域控制器和 IT 管理员提供的信息为准。

4. 再排查 Kerberos 绑定

TCP/TLS 连接成功后，才会进入 LDAP 身份验证和操作阶段。如果连接成功但绑定失败，应检查 Kerberos 凭据、客户端的 Kerberos 配置、服务主体名称和服务器策略。仅凭当前的连接重置错误，无法判断 Kerberos 配置有误。

建议收集的信息

记录 ldap.DialURL 返回的完整错误，并请 IT 确认域控制器地址、LDAPS 端口、证书对应的 DNS 名称，以及服务器是否会关闭未认证客户端的连接。结合 nc 和 openssl s_client 的结果，通常可以判断问题出在 TCP 可达性、TLS 握手还是后续 LDAP/Kerberos 阶段。

备注：内容仅供参考。