mongodb community 版不支持 ldap 认证，启动时识别不了--ldapbinddn等参数会报unrecognized option；仅 enterprise 或 atlas 支持原生 ldap，且自 8.0 起已弃用。
因为本地认证无法满足企业对账号生命周期、权限统一管控和审计合规的基本要求，而 LDAP 是事实上的企业级身份中枢——但迁移不是“开个开关”就能成，得先看清 MongoDB 的版本边界和认证路径。
Community 版本根本不能配 LDAP 参数
看到 --ldapBindDn 或配置文件里写 security.ldap.servers 就报错？不是你配错了，是 Community 版本压根不识别这些字段。启动时直接拒绝，日志里会明确提示 unrecognized option。连参数解析都过不了，更别说发起 LDAP 请求。
- 运行
mongod --version，输出里没有Enterprise字样，就别在配置里留任何ldap.*配置项——删干净，否则服务起不来 - 社区用户如果硬要集中认证，唯一可行路径是应用层桥接：用
ldapjs或类似库先验 LDAP 凭据，再以预设的 SCRAM 用户连 MongoDB - Ops Manager 的 LDAP 登录和 MongoDB 实例的认证完全无关，它只管自己控制台，不影响数据库访问控制逻辑
Enterprise 版本启用 LDAP 必须走 TLS 加密通道
MongoDB Enterprise 强制要求 LDAP 通信加密，ldap.transportSecurity: none 不被接受。哪怕 LDAP 服务跑在 localhost，也必须配 ldaps:// 或启用 StartTLS（对应 ldap.transportSecurity: tls）。
-
ldap.uri必须以ldaps://开头，或配合ldap.transportSecurity: tls+ 端口 389 使用 -
ldap.tlsCAFile指向的是 LDAP 服务器证书的根 CA 文件，不是自签名证书本身；若用自签证书，别碰ldap.tlsAllowInvalidCertificates——它对 LDAP 连接无效 -
ldap.bindQueryUser不是管理员账号，而是 MongoDB 用来搜索用户 DN 的“查询代理”，权限只需能执行search，无需bind全域权限
MongoDB 8.0 起 LDAP 已标记为弃用
从 MongoDB 8.0 开始，官方文档已明确标注 LDAP 身份验证和授权“deprecated”，虽仍可用至 8.x 生命周期结束，但未来主版本将移除。这不是警告，是路线图信号。
- 当前用 LDAP 的团队，应同步评估替代方案：x.509 证书认证更稳定，Kerberos 在 Windows 域环境集成度更高
- LDAP 授权依赖
security.ldap.authz.queryTemplate和组 DN 到角色名的精确匹配，一旦 LDAP 组结构变更，MongoDB 角色权限会立即失效，且无中间缓存兜底 - 使用
saslauthd方式时，Linux 上默认开启身份验证缓存，缓存未过期前即使 LDAP 服务器宕机或用户权限被撤回，saslauthd仍会放行——这在强审计场景下属于策略盲区
真正卡住落地的，往往不是技术能不能做，而是“谁负责维护 LDAP 映射逻辑”“凭证变更后多久同步到 MongoDB 角色”“审计日志里如何追溯 LDAP 用户的实际操作”——这些都不是配置几个参数就能闭环的问题。
