MongoDB企业版集成LDAP必须满足四重前提：仅Enterprise版支持（社区版静默忽略配置）、强制TLS加密通信、ldap.bindQueryUser为专用查询代理账号、副本集需先完成security.authorization等三项安全基线；LDAP已在8.0被弃用，建议新项目评估OIDC等云原生替代方案。
MongoDB 企业版集成 LDAP 不是“开个开关就能用”，必须满足版本、TLS、代理账号、权限基线四重前提，缺一不可；社区版完全不支持，且不会报错，只会静默忽略配置。
确认 MongoDB 是 Enterprise 版本
社区版 mongod 启动时遇到 ldap.bindQueryUser 或 ldap.transportSecurity 等参数会直接跳过，不提示、不报错、不生效——这是最常被误判的点。
- 运行
mongod --version，输出中必须明确含Enterprise字样（如db version v8.0.5-enterprise） - Atlas 用户需确认订阅层级为
Advanced或更高，并在 Organization 级开启 LDAP 集成（Project 级无法单独启用） - 别尝试给社区版打补丁或替换 SASL 库——底层认证流程由 Enterprise 专有模块控制，不可插件化扩展
强制 TLS 加密通信不可绕过
MongoDB Enterprise 不接受明文 LDAP 连接，ldap.transportSecurity: none 会导致服务启动失败，日志固定报错：Failed to initialize LDAP client: LDAP server URI is invalid。
-
ldap.uri必须以ldaps://开头（端口默认 636），或设为ldap://host:389+ 显式启用ldap.useStartTls: true -
ldap.tlsCAFile必须指向 LDAP 服务器证书的根 CA 文件（不是自签名证书本身），用于校验 LDAPS 证书有效性 -
ldap.tlsAllowInvalidCertificates对 LDAP 连接完全无效——它只影响 MongoDB 自身发起的 HTTPS 请求（如 Atlas 调用） - 若 LDAP 用通配符证书（如
*.corp.example.com），确保ldap.uri中的 host 域名匹配其 SAN 字段
ldap.bindQueryUser 是查询代理，不是管理员
这个账号仅用于搜索用户 DN，权限只需具备“读取用户条目”即可，**绝不能填域管理员账号**。填错会导致 bind 成功但 search 失败，现象是：客户端能连上，但所有用户都报 Authentication failed，日志里却看不到 LDAP search 请求。
- AD 场景下推荐使用专用 service account，如
CN=svc-mongodb,CN=Users,DC=corp,DC=example,DC=com - OpenLDAP 场景下可用绑定 DN 类似
cn=proxy,ou=services,dc=example,dc=com - 该账号密码通过
ldap.bindQueryPassword配置，若用 Kubernetes Operator，应存入 Secret 的data字段（Base64 编码），而非stringData - 不要复用同一套
bindQueryUser跨区域使用——多区域部署时，每个区域需独立配置对应的服务账号和证书路径
副本集启用前必须完成三项安全基线
LDAP 认证依赖底层授权体系就位，漏掉任意一条都会导致后续 db.getSiblingDB("$external").createUser() 静默失败或返回 not authorized，而 mongod 启动日志里没有任何提示。
-
security.authorization: true必须开启，否则$external数据库不可写 - 所有副本集成员必须使用相同
keyFile（或统一 x.509 内部认证），否则rs.status()中节点状态卡在STARTUP2或REMOVED - 必须先在
admin数据库创建至少一个本地 root 用户（如root角色），否则无法执行$external用户管理命令
LDAP 在 MongoDB 8.0 已被标记为弃用，虽仍可用，但未来主版本会移除；生产环境新项目建议评估 MONGODB-OIDC 或 AWS-IAM 替代路径——它们更适配云原生架构，且不受操作系统 LDAP 库同步阻塞影响（如 RHEL 上 libldap 链接导致的延迟毛刺）。
