MongoDB企业版提供LDAP身份验证能力，可以把账号体系托管到Active Directory或OpenLDAP这类目录服务上统一管理。但在实际部署中，偶尔会遇到连接数据库时报故障码1190的情况，错误信息通常是LDAP authentication failed或者Timed out while waiting for LDAP server response。这个故障的本质是MongoDB在规定时间内没有从LDAP服务器拿到认证响应，可能是网络不通、服务器负载过高，也可能是配置写错导致根本没找到正确的目录节点。下面从原理到实操，把这个问题的排查思路完整梳理一遍。
一、先弄清LDAP认证的流程和1190产生的原因
MongoDB的LDAP认证走的是简单绑定（Simple Bind）方式。客户端把用户名和密码发给mongod，mongod提取出用户名中的DN或者通过转换模板拼出DN，然后拿着这个DN和密码去LDAP服务器发起绑定请求。LDAP服务器验证通过后返回成功，mongod再检查该用户是否在MongoDB内有对应的角色授权，整个流程才算完成。
故障码1190对应的是这个流程中的超时环节。mongod默认等待LDAP响应的时间由ldapTimeouts相关参数控制（老版本里是ldap.timeoutMS），超过这个时间没有收到响应就报1190。需要注意的是，1190和密码错误、DN找不到这类"立刻被拒绝"的错误不同，它是等了很久才失败的，所以排查重心应该放在网络链路和LDAP服务器状态上，而不是一上来就怀疑密码写错了。
常见的触发场景有这几种：第一，MongoDB服务器到LDAP服务器的389或636端口被防火墙拦截；第二，LDAP服务器负载过高或者宕机；第三，TLS协商失败导致连接挂起；第四，DNS解析慢，每次认证前都要花几秒去解析LDAP主机名。理解了这些场景，排查时就能有的放矢。
二、排查网络连通性和端口状态
排查的第一步永远是确认MongoDB所在服务器能不能正常访问LDAP服务器。用telnet或者nc测试端口连通性：
# 测试LDAP标准端口389 telnet ldap.example-ipipp.com 389 # 测试LDAPS端口636 nc -zv ldap.example-ipipp.com 636 # 观察DNS解析耗时 time nslookup ldap.example-ipipp.com
如果端口不通，重点检查MongoDB服务器和LDAP服务器之间的防火墙规则、安全组配置。云环境里还要注意跨可用区或跨VPC的网络ACL。如果DNS解析耗时超过一秒，建议在MongoDB服务器的hosts文件中固化LDAP服务器地址，或者修复内网DNS，避免每次认证都卡在解析阶段。
端口通了之后，用ldapsearch直接从MongoDB服务器上发起一次查询，验证应用层是否正常。这一步很关键，它能区分开"网络问题"和"配置问题"：
# 需要安装 openldap-clients ldapsearch -H ldap://ldap.example-ipipp.com:389 \ -D "CN=svc-mongo,OU=ServiceAccounts,DC=example-ipipp,DC=com" \ -w 'BindPassword' \ -b "DC=example-ipipp,DC=com" \ "(sAMAccountName=testuser)"
如果ldapsearch能正常返回结果，说明链路和凭据都没问题，1190大概率是MongoDB自身的超时参数设置过短，或者mongod进程内部资源耗尽导致的，可以进入第三步继续排查。如果ldapsearch本身也超时，那问题就锁定在LDAP服务端或中间网络设备上。
三、检查MongoDB的LDAP配置参数
确认链路没问题后，回头检查mongod配置文件中LDAP相关的参数。一个典型的配置如下：
security:
ldap:
servers: "ldap.example-ipipp.com:389"
transportSecurity: none
timeoutMS: 20000
bind:
method: simple
bindDN: "CN=svc-mongo,OU=ServiceAccounts,DC=example-ipipp,DC=com"
password: "BindPassword"
userToDNMapping:
'[ { match: "(.+)", ldapQuery: "DC=example-ipipp,DC=com??sub?(sAMAccountName={0})" } ]'
authorization: enabled
这里有几个参数直接影响1190的出现频率。timeoutMS是单次LDAP操作的超时时间，默认值在一些版本里只有10秒，如果LDAP服务器响应偏慢，可以适当调大到20000甚至30000毫秒。但要注意，调大只是缓解症状，如果LDAP服务器本身要二十秒才能响应一次查询，应该优先解决目录服务的性能问题，比如索引缺失、同步延迟等。
userToDNMapping中的ldapQuery如果搜索范围设置得太大（比如从域根开始全子树搜索），每次认证都要扫描大量条目，很容易超时。优化方法是尽量把查询起点下移到用户所在的OU，并确保sAMAccountName在LDAP端有索引。另外transportSecurity如果配置为tls但证书校验失败，有时也会表现为超时而不是明确的证书错误，可以用openssl验证一下证书链：
openssl s_client -connect ldap.example-ipipp.com:636 \ -CAfile /etc/ssl/certs/company-ca.pem
如果证书校验报错，要么把企业CA证书导入MongoDB服务器的信任库并在配置中通过ldap.transportSecurity.caFile指定，要么临时降级为none来验证是否是证书问题（生产环境不建议长期关闭TLS）。
四、凭据、日志与服务端的进一步定位
配置参数都没问题的话，接下来看mongod日志。1190发生时日志里通常有更详细的线索，比如LDAP server unavailable、connection reset或者具体的LDAP结果码。把日志级别临时调高能获得更多信息：
// 在mongosh中执行，临时开启LDAP相关的详细日志
db.adminCommand({
setParameter: 1,
logComponentVerbosity: {
network: { verbosity: 3 },
accessControl: { verbosity: 3 }
}
});
日志显示绑定被拒绝的话，要检查Bind DN账号的状态：账号是否被锁定、密码是否过期、服务账号是否被移出了原来的OU。这些都是Active Directory运维中很常见的变更，往往LDAP侧一次清理操作后MongoDB这边就开始报错。
最后在LDAP服务端确认健康状态。以OpenLDAP为例，查看 slapd 进程的连接数和负载；以Active Directory为例，用事件查看器查看目录服务的审核日志，确认认证请求是否真的到达了域控。如果请求根本没到，问题一定在中间网络；如果到达了但处理慢，就是目录服务本身的性能瓶颈，比如域控内存不足、全局编录未就绪等。
五、日常预防的几点建议
为了避免1190反复出现，建议做好这几件事：配置多台LDAP服务器实现容灾，参数写成server1:389,server2:389的形式，mongod会自动切换；为LDAP认证设置监控告警，一旦认证延迟明显上升就提前介入；Bind DN使用专用的服务账号并纳入到期提醒，避免密码过期导致全量认证失败；定期从MongoDB服务器上跑一次ldapsearch做链路巡检，把故障发现提前到用户报障之前。
总的来说，故障码1190虽然看起来吓人，但排查路径是很清晰的：先确认网络和端口，再验证LDAP链路和凭据，然后检查MongoDB配置中的超时与映射规则，最后借助日志和服务端视角收尾。按这个顺序走下来，绝大多数LDAP认证超时问题都能在半小时内定位到根因。
MongoDB故障码1190LDAP认证超时MongoDB LDAP配置修改时间：2026-09-12 12:28:41