MongoDB集成Active Directory配置Kerberos身份验证

首先澄清一个最关键的前提，这也是很多团队初次尝试时最容易触碰的红线：MongoDB 必须使用 Enterprise 版本才能与 Active Directory 进行 Kerberos 集成，Community 版本完全不提供此功能。一旦你遇到 Unsupported SASL mechanism: GSSAPI 这类报错，基本可以判定是版本问题，无需在其他配置上浪费时间。

再次强调：MongoDB 与 Active Directory 的 Kerberos 集成必须依赖 Enterprise 版本，Community 版无此能力。若见到 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

这里隐藏着大量故障根源。MongoDB 启动时若报 GSSAPI Error: Unspecified GSS failure，或连接后认证失败，90% 的原因在于 SPN 与实际绑定的地址不匹配。

Kerberos 协议的核心机制要求：客户端发出的 mongodb/hostname@REALM 请求，必须能被 KDC（密钥分发中心）正确解析。解析依据是 DNS 中的 A 记录或本机的 hosts 映射。关键点在于：hostname 必须是完整域名（FQDN），像 localhost、127.0.0.1 或短主机名都无法通过验证。

具体操作可以这样理解：

1. 在 AD 域控上注册 SPN：运行 kadmin -p admin/admin@EXAMPLE.COM addprinc -randkey mongodb/m1.example.com@EXAMPLE.COM，告知 KDC 你的 MongoDB 服务身份。
2. 导出 keytab 文件：执行 kadmin -p admin/admin@EXAMPLE.COM ktadd -k /etc/mongodb.keytab mongodb/m1.example.com@EXAMPLE.COM，将服务密钥妥善保存。
3. 配置 MongoDB 绑定地址：启动 MongoDB 时，需在参数中使用 --bind_ip m1.example.com，或在配置文件中设置 net.bindIp: m1.example.com。切勿偷懒写成 0.0.0.0 或具体 IP 192.168.1.10，这会导致 SPN 匹配失败。
4. 验证 DNS 解析：执行 nslookup m1.example.com，确认返回正确的 IP 地址。同时检查 /etc/hosts 文件中是否存在错误的映射，避免本地解析将域名指向其他位置。

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

这是一个极易被忽视的细节。在 Kerberos 协议中，alice@EXAMPLE.COM 与 alice@example.com 是两个完全不同的主体（principal）。如果在 MongoDB 创建用户时，Realm 的大小写与 KDC 中定义的不同，所有认证都会静默失败。日志中仅会出现干巴巴的 Authentication failed，不会给出具体原因。

• 因此，使用 mongosh 创建用户时，命令必须精确：db.getSiblingDB("$external").createUser({user: "alice@EXAMPLE.COM", roles: [{role: "readAnyDatabase", db: "admin"}]})。其中 Realm（EXAMPLE.COM）必须与 KDC 中的定义完全一致，通常采用全大写。
• 可以通过 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 只负责“你是谁”的身份验证，而“你能做什么”的权限控制，则由 MongoDB 通过 LDAP 查询 AD 来完成。如果用户能成功登录，但没有任何数据库访问权限，那么问题大概率出在 LDAP 绑定或角色映射上，而非 Kerberos 本身。

• 启动 MongoDB 时，--ldapBindMethod 应设为 simple 或 ssl，--ldapTransportSecurity 必须开启 tls。若 AD 的 LDAPS 端口（636）不可达，MongoDB 会静默回退到明文连接，但大多数企业的安全策略禁止这种行为。
• --ldapQueryTemplate 中的 %s 会被替换为 Kerberos principal 的全名（如 alice@EXAMPLE.COM）。然而，AD 中的 userPrincipalName 属性值通常是 alice@example.com（小写）。因此，模板中可能需要做大小写归一化处理，例如写成 (userPrincipalName=%u@EXAMPLE.COM)，其中 %u 代表用户名部分（不含 realm）。
• 角色映射还有个常见陷阱：AD 返回的 group DN（例如 CN=mgdb-readers,CN=Users,DC=example,DC=com）必须与你在 MongoDB admin 数据库中已创建的角色名完全一致，包括大小写和空格。换言之，如果 AD 返回的是 mgdb-readers，你就要在 MongoDB 中创建一个名为 mgdb-readers 的角色，而不是 MGDB-READERS。

最后，也是最容易被忽视的一点：Kerberos + AD 集成并非一个“配完就能用”的线性流程。它本质上是三个独立子系统（KDC、AD/LDAP、MongoDB）的协同工作。任何一个环节出错——DNS 解析、系统时间同步（Kerberos 要求客户端与服务器的时钟偏差在 5 分钟以内）、证书信任链，或者大小写约定——都可能导致看似随机的认证失败。而且，错误日志往往不会直接指明根因，你需要根据上述步骤逐一排查，方能定位问题所在。