GridFS不支持LDAP授权，需在mongod配置LDAP并在admin库显式创建$external用户及角色；权限继承依赖saslauthd返回的完整组列表与预定义角色匹配。
检查 $external 用户是否已创建并映射到 LDAP 账号
LDAP 用户在 MongoDB 中不以本地用户形式存在，而是通过 $external 身份验证数据库进行识别。必须先确认该用户已在 admin 数据库中显式创建（哪怕只是空角色），否则即使 LDAP 认证成功，也无法被授权系统识别。
执行以下命令验证：
use admin
db.getUser("CN=alice,OU=Users,DC=example,DC=com", { db: "$external" })
如果返回 null，说明尚未创建该用户 —— 这是权限继承失败最常见的原因，不是 LDAP 配置错了，而是 MongoDB 侧缺少用户元数据。
- 必须用完整 LDAP DN（如
CN=alice,OU=Users,DC=example,DC=com）作为用户名，不能只用alice -
db参数必须指定为"$external"，否则默认查admin本地库，必然查不到 - 若用户不存在，需用
db.createUser()显式创建，并至少赋予一个角色（如{ roles: [] }），后续权限才可通过 LDAP 组继承
确认 LDAP 组是否正确映射到 MongoDB 角色
MongoDB 不自动读取 LDAP 组成员关系并赋权；它依赖你在 admin 数据库中预先定义的组映射规则。这些规则存储在 system.roles 或（更常见）通过 db.createRole() 创建的自定义角色中，且角色的 role 字段必须显式引用 LDAP 组的 DN 或别名。
例如，若 LDAP 中有一个组 CN=admins,OU=Groups,DC=example,DC=com，你必须确保：
- 该组已被添加为
admin数据库中的一个角色，比如名为"ldap-admins" - 该角色的
privileges包含实际权限（如clusterAdmin），且roles字段为空或仅含其他继承角色 - 用户所属的 LDAP 组与角色名/标识之间存在明确绑定 —— MongoDB Enterprise 不解析 LDAP 的
memberOf属性，而是靠saslauthd或操作系统库返回的组列表匹配你配置的角色名
运行 db.getRole("ldap-admins", { showPrivileges: true }) 确认角色定义无误，再检查 db.runCommand({ connectionStatus: 1 }).authInfo.authenticatedUserRoles 看当前会话是否列出了该角色。
排查 saslauthd 返回的组信息是否完整
LDAP 权限继承失败，80% 源于 saslauthd 没有把用户所属的组完整传给 MongoDB。MongoDB Enterprise 本身不查询 LDAP 目录，它只信任 saslauthd 返回的 userGroups 列表 —— 如果这个列表为空或不全，角色就无法匹配。
验证方式：在 MongoDB 服务器本机手动触发认证测试：
testsaslauthd -u "alice" -p "password" -f /var/run/saslauthd/mux
观察输出是否包含类似 userGroups: CN=admins,OU=Groups,DC=example,DC=com 的行。如果没有：
- 检查
/etc/saslauthd.conf中ldap_group_base、ldap_group_search_filter是否正确（例如(member=%U)或(uniqueMember=%U)） - 确认
saslauthd启动时加载了ldap机制（MECH=ldap或MECHANISMS="ldap"） - 注意：某些 OpenLDAP 配置下，
%U变量不会自动展开为完整 DN，需改用%s或硬编码搜索上下文
验证 TLS 和证书链是否阻断组属性读取
当使用 LDAPS（端口 636）或 StartTLS 时，saslauthd 若无法验证 LDAP 服务器证书，可能静默降级为不读取组属性 —— 尤其在 RHEL/CentOS 等默认启用证书校验的系统上。
检查 /var/log/messages 或 journalctl -u saslauthd 是否出现类似 ldap_simple_bind_s: Can't contact LDAP server 或 TLS certificate verification: depth 0, error 20 的日志。
- 临时绕过验证（仅用于诊断）：在
/etc/saslauthd.conf加入ldap_tls_checkpeer no - 长期方案：将 LDAP CA 证书导入系统信任库（如
/etc/pki/ca-trust/source/anchors/），再运行update-ca-trust - 注意：Windows 平台 MongoDB Enterprise 不支持
saslauthd，必须走操作系统原生 LDAP 库，此时组解析行为由 Windows Active Directory 策略和ldapjs兼容层决定，调试难度更高
真正卡住的地方往往不在 MongoDB 配置里，而在 saslauthd 是否拿到了完整的组列表、以及那个列表能否被 MongoDB 正确匹配成已定义的角色 —— 这两个环节都无声无息，必须逐层验证输出，不能只看“登录成功”就认为权限到位。
