怎样实现MongoDB与Active Directory集成_配置Kerberos网络身份验证

MongoDB 与 Active Directory 集成必须使用 Enterprise 版本，Community Edition 完全不支持 Kerberos；若出现 Unsupported SASL mechanism: GSSAPI 错误，基本可确认是版本问题。

MongoDB 与 Active Directory 集成必须使用 Enterprise 版本，Community Edition 完全不支持 Kerberos；若看到 Unsupported SASL mechanism: GSSAPI 错误，基本可确认是版本问题。

确认 MongoDB 是 Enterprise 版本

运行 mongod --version，输出中必须包含 modules: enterprise 或 modules: subscription。Community 版即使编译时带 SASL 支持，也无法启用 GSSAPI 认证机制。Kerberos 集成不是“配置开关”，而是二进制级能力，换包比调参数更重要。

• 在容器环境中（如 Docker），确保拉取的是 mongo:enterprise 镜像，而非 mongo:latest（默认为 Community）
• RHEL/CentOS 上通过 yum list installed | grep mongo 检查包名是否含 mongodb-enterprise-server
• Windows 安装目录下检查 mongod.exe 属性“详细信息”页中的“产品名称”，应为 “MongoDB Enterprise Server”

服务主体（SPN）和 keytab 文件必须匹配 FQDN

mongod 启动时若报 GSSAPI Error: Unspecified GSS failure 或连接后认证失败，90% 是 SPN 与实际绑定地址不一致。Kerberos 要求客户端发起的 mongodb/hostname@REALM 必须能被 KDC 正确解析，而解析依据就是 DNS 中的 A 记录或 hosts 映射 —— 且该 hostname 必须是完整域名（FQDN），不能是 localhost、127.0.0.1 或短主机名。

• 在 AD 域控上执行：kadmin -p admin/[email protected] addprinc -randkey mongodb/[email protected]
• 导出 keytab：kadmin -p admin/[email protected] ktadd -k /etc/mongodb.keytab mongodb/[email protected]
• mongod 启动参数中必须用 --bind_ip m1.example.com（或配置文件中 net.bindIp: m1.example.com），不能写成 0.0.0.0 或 192.168.1.10
• 验证 DNS 可解析：nslookup m1.example.com 返回正确 IP；同时确认该主机的 /etc/hosts 中无错误映射覆盖

创建 $external 用户时 Realm 大小写必须严格一致

AD 用户 [email protected] 和 [email protected] 在 Kerberos 协议中是两个完全不同的 principal。MongoDB 创建用户时若 Realm 大小写错误，后续所有认证都会静默失败（日志里只显示 Authentication failed，无具体原因）。

• 使用 mongosh 连接后执行：db.getSiblingDB("$external").createUser({user: "[email protected]", roles: [{role: "readAnyDatabase", db: "admin"}]})
• Realm 名称必须与 KDC 中定义的 realm 完全一致（通常全大写），可通过 klist -k /etc/mongodb.keytab 查看 keytab 中存储的 principal 格式
• Linux 客户端连接时，需确保本地 /etc/krb5.conf 的 default_realm 与 AD realm 一致，且 realms 段落中 KDC 地址正确
• 若 AD 使用多 realm 信任关系，MongoDB 不自动跨 realm 解析，必须显式指定完整 principal 名

LDAP 授权阶段容易忽略 TLS 验证和 DN 映射格式

Kerberos 只管身份验证，权限控制依赖 LDAP 查询 AD。若用户能登录但无任何数据库访问权限，问题大概率出在 LDAP 绑定或角色映射上，而非 Kerberos 本身。

• mongod 启动必须带 --ldapBindMethod=simple（或 ssl）和 --ldapTransportSecurity=tls；若 AD LDAPS 端口（636）不可达，会静默回退到明文，但多数企业策略禁止此行为
• --ldapQueryTemplate 模板中，%s 替换的是 Kerberos principal 全名（如 [email protected]），但 AD 中 userPrincipalName 属性值通常是 [email protected]（小写），需在模板中做大小写归一化处理，例如：(userPrincipalName=%[email protected])，其中 %u 是用户名部分（不含 realm）
• 角色映射要求 AD 返回的 group DN 必须与 MongoDB admin 数据库中已存在的角色名**完全一致**，包括大小写和空格；例如 AD 返回 CN=mgdb-readers,CN=Users,DC=example,DC=com，则必须提前在 MongoDB 中创建名为 mgdb-readers 的角色（不是 MGDB-READERS）

最常被跳过的一步：Kerberos + AD 集成不是“配完就能用”的线性流程，而是三个独立子系统（KDC、AD/LDAP、MongoDB）的协同。任何一个环节的 DNS、时间同步（Kerberos 要求客户端和服务端时钟偏差 ≤ 5 分钟）、证书信任链或大小写约定出错，都会导致看似随机的认证失败，且错误日志往往不直接暴露根因。