对于 AI 代理:可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单

配置 Kerberos 和 Active 目录 授权

MongoDB Enterprise支持在LDAP服务器中查询经过身份验证的用户所属的LDAP群组。 MongoDB将每个返回群组的LDAP标识名 (DN) 映射到admin 数据库上的角色。 MongoDB根据映射的角色及其关联的权限对用户进行授权。有关更多信息,请参阅LDAP授权。

MongoDB Enterprise 支持使用 Kerberos 服务进行身份验证。Kerberos 是一种面向大型客户端/服务器系统的行业标准身份验证协议。

本教程介绍如何配置 MongoDB,以借助平台库通过 Kerberos 服务器执行身份验证,并通过 Active Directory (AD) 服务器执行授权。

重要

在继续之前,请充分熟悉以下主题:

AD 的完整说明超出了本教程的范围。本教程假定读者事先了解 AD

MongoDB 支持使用 SASL 机制在 MongoDB Server 和AD之间进行绑定。 SASL、SASL 机制或给定 SASL 机制的特定AD配置要求的完整描述超出了本教程的范围。 本教程假定您已了解 SASL 及其相关主题。

设置和配置 Kerberos 部署超出了本文档的范围。本教程假设您已为 MongoDB 部署中的每个 mongodmongos 实例配置了 Kerberos 服务主体,并且对于每个 mongodmongos 实例,您都有一个有效的密钥表文件。

对于副本集和分片集群,请确保配置使用完全限定的域名 (FQDN),而不是 IP 地址或未限定的主机名。您必须使用 GSSAPI 的 FQDN 才能正确解析 Kerberos Realm 并允许连接。

要验证您是否使用 MongoDB Enterprise,请将 --version 命令行选项传递给 mongodmongos

mongod --version

在该命令的输出中,请查找字符串 modules: subscriptionmodules: enterprise,以确认您使用的是 MongoDB Enterprise 二进制文件。

本教程介绍如何为Kerberos身份验证和 AD授权配置MongoDB

要在自己的MongoDB服务器上执行此过程,您必须根据自己的特定基础架构(尤其是Kerberos配置、构建AD查询或管理用户)修改给定过程。

默认情况下,MongoDB 在绑定到 AD 服务器时会创建 TLS/SSL 连接。 这需要配置 MongoDB 服务器的主机,使其能够访问 AD 服务器的证书颁发机构 (CA) 证书。

本教程提供所需主机配置的说明。

本教程假设您可以访问 AD 服务器的 CA 证书,并可以在 MongoDB 服务器上创建证书副本。

本教程使用以下示例AD对象作为所提供查询、配置和输出的基础。 每个对象仅显示可能属性的子集。

dn:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
userPrincipalName: bob@marketing.example.com
memberOf: CN=marketing,CN=Users,DC=example,DC=com
dn:CN=alice,CN=Users,DC=engineering,DC=example,DC=com
userPrincipalName: alice@engineering.example.com
memberOf: CN=web,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com
dn:CN=sam,CN=Users,DC=dba,DC=example,DC=com
userPrincipalName: sam@dba.example.com
memberOf: CN=dba,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com
dn:CN=joe,CN=Users,DC=analytics,DC=example,DC=com
userPrincipalName: joe@analytics.example.com
memberof: CN=marketing,CN=Users,DC=example,DC=com
dn:CN=marketing,CN=Users,DC=example,DC=com
member:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
member:CN=joe,CN=Users,DC=analytics,DC=example,DC=com
dn:CN=engineering,CN=Users,DC=example,DC=com
member:CN=web,CN=Users,DC=example,DC=com
member:CN=dba,CN=users,DC=example,DC=com
dn:CN=web,CN=Users,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com
dn:CN=dba,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com
dn:CN=PrimaryApplication,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com

本教程使用用户名和密码在 AD服务器上执行查询。提供的凭证必须在 AD服务器上拥有足够的特权,以支持与 security.ldap.userToDNMapping security.ldap.authz.queryTemplate 相关的查询。

MongoDB LDAP 授权要求副本集中的每个 mongod 至少使用 MongoDB 3.4.0或更高版本。

MongoDB LDAP 授权要求分片集群中的每一个 mongodmongos 都至少使用 MongoDB 3.4.0 或更高版本。

1

要通过 TLS/SSL 连接到 AD (AD)服务器,mongod mongos 需要访问权限AD 服务器的证书颁发机构 (CA) 证书。

在Linux上,通过 ldap.conf文件中的 TLS_CACERTTLS_CACERTDIR 选项指定 AD 服务器的 CA 证书。

平台的包管理器在安装 MongoDB Enterprise 的libldap 依赖项时创建 ldap.conf 文件。有关配置文件或引用选项的完整文档,请参阅 ldap .conf

在 Microsoft Windows上,使用平台的档案管理工具加载AD服务器的证书颁发机构 (CA) 证书。 确切的档案管理工具取决于Windows版本。 要使用该工具,请参阅适用于您的Windows版本的文档。

如果mongodmongos无法访问AD CA 文件,则他们无法创建与 Active Directory 服务器的 TLS/SSL 连接。

或者,将 security.ldap.transportSecurity 设置为 none 以禁用 TLS/SSL。

警告

transportSecurity 设置为 none 可在 MongoDB 和 AD 服务器之间传输明文信息,包括用户凭证。

2

对于在 Windows 操作系统上运行的 MongoDB 服务器,必须使用 setspn.exe 将服务主体名称 (SPN) 分配给运行 MongoDB 服务的帐户。

setspn.exe -S <service>/<fully qualified domain name> <service account name>

例子

例如,如果 mongod 作为名为 mongodb 的服务在 mongodbserver.example.com 上运行,服务帐户名称为 mongodb_dev@example.com,则分配 SPN 的命令如下所示:

setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com

注意

Windows Server 2003 不支持setspn.exe -S。有关 setspn.exe 的完整文档,请参阅 setspn.exe。

3

对于 Linux 平台上运行的 MongoDB 服务器,必须确保服务器具有特定于该服务器上运行的 MongoDB 实例的密钥表文件的副本。

您必须授予运行 MongoDB 服务的 Linux 用户对密钥表文件的读取权限。记下密钥表文件位置的完整路径。

4

使用mongosh --host--port 选项,使用 连接到MongoDB服务器。

mongosh --host <hostname> --port <port>

如果您的MongoDB服务器当前强制执行身份验证,则您必须以具有角色管理特权(例如adminuserAdminuserAdminAnyDatabase --authenticationMechanism提供的特权)的用户身份在 数据库中进行身份验证。包括适用于MongoDB Server 配置的身份验证机制的相应 。

mongosh --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"

注意

对于Windows MongoDB部署,应将 mongosh 替换为 mongo.exe

5

要使用 AD管理MongoDB用户,您需要在可以创建和管理角色的 admin数据库上创建至少一个角色,例如 userAdmin userAdminAnyDatabase 提供的角色。

角色的名称必须与 AD 群组的标识名完全匹配。该组必须至少有一个 AD 用户作为节点。

给定可用的 Active Directory 群组,执行以下操作:

  • 创建以 AD群组CN=dba,CN=Users,DC=example,DC=com 命名的角色,并且

  • 为其分配 admin 数据库上的 userAdminAnyDatabase 角色。

var admin = db.getSiblingDB("admin")
admin.createRole(
{
role: "CN=dba,CN=Users,DC=example,DC=com",
privileges: [],
roles: [ "userAdminAnyDatabase" ]
}
)

您也可以为用户应具有用户管理权限的每个数据库授予 userAdmin 角色。这些角色为角色创建和管理提供必要的权限。

重要

配置MongoDB角色、AD 群组或群组成员身份时,请考虑应用最小权限原则原则。

6

MongoDB 配置文件是具有 .conf 文件扩展名的纯文本 YAML 文件。

  • 如果您正在升级现有的 MongoDB 部署,请复制当前配置文件并从该副本开始工作。

  • (仅限 Linux)如果这是新部署,并且您使用了平台的包管理器来安装 MongoDB Enterprise,则该安装将包含 /etc/mongod.conf 默认配置文件。使用该默认配置文件,或复制该文件以供使用。

  • 如果不存在此类文件,请创建一个扩展名为 .conf 的空文件,然后从该新配置文件进行操作。

7

在MongoDB配置文件中,将 security.ldap.servers设立为 AD服务器的托管和端口。如果您的 AD 基础架构包含多个用于复制的AD 服务器,请将服务器的托管和端口指定为 security.ldap.servers 的逗号分隔列表。

例子

要连接到位于 activedirectory.example.net 的 AD服务器,请在配置文件中包含以下内容:

security:
ldap:
servers: "activedirectory.example.net"

MongoDB 必须绑定到AD服务器才能执行查询。 默认情况下,MongoDB 使用简单身份验证机制将自身绑定到AD服务器。

或者,您可以在配置文件中配置以下设置,以使用 SASL 绑定到 AD服务器:

本教程使用默认的 simple LDAP 身份验证机制。

8

在 MongoDB 配置文件中,将 security.authorization 设置为enabled,并将 setParameter authenticationMechanisms 设置为 GSSAPI

要启用通过 Kerberos 进行身份验证,请在配置文件中包含以下内容:

security:
authorization: "enabled"
setParameter:
authenticationMechanisms: "GSSAPI"
9

在MongoDB配置文件中,将security.ldap.authz.queryTemplate 设立为 RFC4516 格式的LDAP查询URL模板。

在模板中,您可以使用以下任一项:

  • {USER} 占位符,用于将通过身份验证的用户名替换到 LDAP 查询 URL 中。

  • {PROVIDED_USER} 占位符可在 LDAP 查询中替换为提供的用户名(即在身份验证或 LDAP 转换之前)。

设计查询模板以检索用户的群组。

注意

RFC4515、RFC4516 或 AD 查询的完整描述超出了本教程的范围。本教程中提供的 queryTemplate 仅供示例,可能不适用于您的特定 AD部署。

例子

以下查询模板根据递归群组成员身份返回将 {USER} 列为成员的所有群组。此LDAP查询假定群组对象通过使用 member 属性存储完整的用户标识名 (DN)追踪用户成员资格。该查询包括 LDAP_MATCHING_RULE_IN_CHAIN 的 AD 特定匹配规则 OID 1.2.840.113556.1.4.1941。此匹配规则是LDAP搜索筛选器的特定于 AD 的扩展。

security:
ldap:
authz:
queryTemplate:
"DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"

使用查询模板,MongoDB 将 {USER} 替换为经过身份验证的用户名来查询 LDAP 服务器。

示例,用户以 CN=sam,CN=Users,DC=dba,DC=example,DC=com 身份进行身份验证。 MongoDB根据 queryTemplate 创建LDAP查询,并用经过身份验证的用户名替换 {USER} 令牌。 Active Directory服务器对直接或间接将用户列为成员的任何群组执行递归群组查找。根据 Active Directory 群组,AD服务器返回 CN=dba,CN=Users,DC=example,DC=comCN=engineering,CN=Users,DC=example,DC=com

MongoDB将每个返回的群组DN 映射到 admin数据库上的一个角色。对于每个映射的群组DN,如果 admin数据库上存在其名称与 DN 完全匹配的现有角色,MongoDB将向用户授予分配给该角色的角色和特权。

匹配规则 LDAP_MATCHING_RULE_IN_CHAIN 要求提供身份验证用户的完整 DN。由于Kerberos要求使用用户的 userPrincipalName 进行身份验证,因此您必须使用security.ldap.userToDNMapping 将传入的用户名转换为 DN。下一步将提供有关转换传入用户名以支持queryTemplate 的指导。

10

在MongoDB配置文件中,设立userToDNMapping 以将身份验证用户提供的用户名转换为 AD DN,以支持queryTemplate

例子

以下 userToDNMapping 配置使用 match 正则表达式过滤器来捕获所提供的用户名。在执行查询之前,MongoDB 将捕获的用户名插入到 ldapQuery 查询模板中。

security:
ldap:
userToDNMapping:
'[
{
match : "(.+)",
ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
}
]'

您必须修改给定的示例配置以匹配您的部署。例如,ldapQuery 基本标识名 必须与包含用户实体的基本标识名匹配。可能需要进行其他修改才能支持您的 AD 部署。

例子

用户作为 alice@ENGINEERING.EXAMPLE.COM 进行身份验证。MongoDB 首先应用 userToDNMapping 中指定的任何转换。根据所提供的配置,MongoDB 在 match 阶段捕获用户名并执行 LDAP 查询:

DC=example,DC=com??sub?(userPrincipalName=alice@ENGINEERING.EXAMPLE.COM)

根据配置的 Active Directory 用户,AD服务器应返回 CN=alice,CN=Users,DC=engineering,DC=example,DC=com

然后,MongoDB 执行在 queryTemplate 中配置的 LDAP 查询,用转换后的用户名 CN=alice,CN=Users,DC=engineering,DC=example,DC=com 替换 {USER} 令牌。

重要

如果使用userToDNMapping substitution的 参数来转换群组名称,则替换结果必须是 RFC4514 转义字符串。

11

MongoDB 需要凭证才能在 AD 服务器上执行查询。

在配置文件中配置以下设置:

security:
ldap:
bind:
queryUser: "mongodbadmin@dba.example.com"
queryPassword: "secret123"

在Windows MongoDB服务器上,您可以将 security.ldap.bind.useOSDefaults设立为 true,以使用操作系统用户的凭证,而不是 queryUserqueryPassword

queryUser 必须具有代表 MongoDB 执行所有 LDAP 查询的权限。

12

根据配置要求包括其他选项。例如,如果您希望远程客户端连接到部署,或者部署节点运行在不同的主机上,请指定 net.bindIp 设置。

13

使用 --config 选项启动 MongoDB 服务器,并指定在此过程中创建的配置文件的路径。如果 MongoDB 服务器当前正在运行,请做好适当的准备以停止服务器。

Linux MongoDB Servers

在 Linux 上,您必须指定 KRB5_KTNAME 环境变量,从而指定用于 MongoDB 服务器的密钥表文件路径。

env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>

Microsoft Windows MongoDB Servers

Windows上,您必须按照此过程前面的配置以服务主体帐户身份启动 MongoDB Server:

mongod.exe --config <path-to-config-file>
14

连接到 MongoDB 服务器,以特定用户身份进行身份验证,该用户的直接或可传递群组成员身份对应于 admin 数据库上具有 userAdminuserAdminAnyDatabase 的 MongoDB 角色或具有同等特权的自定义角色。

使用 对MongoDBmongosh 服务器进行身份验证,设立以下选项:

例子

在此过程的前面,您在 admin数据库上配置了 dn:CN=dba,CN=Users,DC=example,DC=com角色所需的权限。该角色对应于一个 AD群组。根据配置的 AD 用户,您可以以用户 sam@dba.example.com 身份进行身份验证并获得所需的权限。

mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanisms="GSSAPI" --authenticationDatabase "$external" --host <hostname> --port <port>

如果没有为-p 命令行选项指定密码,mongosh 会提示输入密码。

Windows MongoDB部署必须使用 mongo.exe 而不是 mongosh

根据已配置 Active Directory 用户,用户可成功通过身份验证并获得相应权限。

注意

如果您想以现有的非$external 用户身份进行身份验证,请将--authenticationMechanism 设立为SCRAM身份验证机制(例如SCRAM-SHA-1SCRAM-SHA-256 )。这要求MongoDB Server 的setParameterauthenticationMechanisms 根据需要包含SCRAM-SHA-1 和/或SCRAM-SHA-256

15

对于 AD服务器上要用于MongoDB授权的每个群组,必须在MongoDB服务器的 admin数据库上创建一个匹配的角色。

例子

以下操作创建一个以 AD群组DN CN=PrimaryApplication,CN=Users,DC=example,DC=com 命名的角色,并为该群组分配适当的角色和权限:

db.getSiblingDB("admin").createRole(
{
role: "CN=PrimaryApplication,CN=Users,DC=example,DC=com",
privileges: [],
roles: [
{ role: "readWrite", db: "PrimaryApplication" }
]
}
)

根据已配置的 Active Directory 群组, MongoDB会向以sam@DBA.EXAMPLE.COMalice@ENGINEERING.EXAMPLE.COM readWrite进行身份验证的用户授予PrimaryApplication 数据库上的 角色。

注意

要管理 admin 数据库上的角色,您必须以拥有以下权限的用户身份进行身份验证:admin 上的 userAdminuserAdminAnyDatabase,或具有同等权限的自定义角色。

16

如果使用在$external数据库上配置的用户升级现有安装,则必须满足每个用户的以下要求,以确保在为 Kerberos 身份验证和AD授权配置 MongoDB 后具有访问权限:

  • 用户在AD服务器上有相应的用户对象。

  • 用户具有AD服务器上相应群组的成员资格。

  • MongoDB 包含以用户的 AD 组命名的 admin 数据库上的角色,以便授权用户保留其权限。

例子

$external 数据库上存在以下用户:

{
user : "joe@ANALYTICS.EXAMPLE.COM",
roles: [
{ role : "read", db : "web_analytics" },
{ role : "read", db : "PrimaryApplication" }
]
}

假设用户属于 AD群组CN=marketing,CN=Users,DC=example,DC=com,则以下操作将创建具有相应特权的匹配角色:

db.getSiblingDB("admin").createRole(
{
role: "CN=marketing,CN=Users,DC=example,DC=com",
privileges: [],
roles: [
{ role: "read", db: "web_analytics" }
{ role: "read", db: "PrimaryApplication" }
]
}
)

根据配置的 queryTemplate,MongoDB 会授权任何在 CN=marketing,CN=Users,DC=example,DC=com 组中拥有直接或传递成员身份的用户在 web_analyticsPrimaryApplication 数据库上执行 read 操作。

重要

为相应的 AD群组配置角色时,请记住,具有该群组成员身份的所有用户都可以接收分配的角色和权限。配置MongoDB角色、AD 群组或群组成员身份时,请考虑应用最小权限原则原则。

如果想要继续允许非 $external 数据库上的用户访问 MongoDB,则必须将 SCRAM 身份验证机制(例如 SCRAM-SHA-1和/或 SCRAM-SHA-256)纳入 setParameter authenticationMechanisms 配置选项中。

setParameter:
authenticationMechanisms: "GSSAPI,SCRAM-SHA-1,SCRAM-SHA-256"

或者,按照上述过程将非$external用户转换到AD

此过程会生成以下配置文件:

security:
authorization: "enabled"
ldap:
servers: activedirectory.example.net"
bind:
queryUser: "mongodbadmin@dba.example.com"
queryPassword: "secret123"
userToDNMapping:
'[
{
match: "(.+)"
ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
}
]'
authz:
queryTemplate: "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"
setParameter:
authenticationMechanisms: "GSSAPI"

重要

需要修改给定的示例配置,以匹配您的AD模式、目录结构和配置。 您的部署可能还需要其他配置文件选项

有关配置角色和权限的更多信息,请参阅:

完成配置步骤后,可以使用 mongokerberos 工具验证配置。

mongokerberos 提供了一种便捷的方法,以验证您的平台的 Kerberos 配置是否与 MongoDB 一起使用,并测试 MongoDB 客户端的 Kerberos 身份验证是否按预期运行。有关更多信息,请参阅 mongokerberos 文档。

mongokerberos 仅在 MongoDB Enterprise 中可用。