Docs 菜单

Docs 主页开发应用程序MongoDB Manual

使用 Kerberos 身份验证和 Active Directory 授权来配置 MongoDB

在此页面上

  • 先决条件
  • 考虑因素
  • 步骤
  • 测试与验证

版本3中的新增功能。 4 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 部署超出了本文档的范围。本教程假设您已为 MongoDBmongos 部署中的每个mongod 实例配置了 Kerberos 服务主体 ,并且为每个 和 mongodmongos实例都有一个有效的 keytab 文件 。

对于副本集和分片集群,请确保配置使用完全限定的域名 (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 Server 的主机,使其有权访问 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.userToDNMappingsecurity.ldap.authz.queryTemplate相关的查询。

MongoDB LDAP 授权要求副本集中的每个mongod至少位于 MongoDB 3上。 4 。 0或更高版本。

MongoDB LDAP 授权要求分片集群中的每个mongodmongos至少位于 MongoDB 3上。 4 。 0或更高版本。

1

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

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

平台的软件包管理器在安装 MongoDB Enterprise 的 依赖项时会创建ldap.conflibldap 文件。有关配置文件或引用选项的完整文档,请参阅 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>

例子

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

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

注意

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

3

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

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

4

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

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

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

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

注意

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

5

要托管ADMongoDB 用户,您需要在可以创建和托管角色的admin数据库上创建至少一个角色,例如userAdminuserAdminAnyDatabase提供的角色。

角色的名称必须与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配置文件是纯文本 YAML 文件,文件扩展名为.conf

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

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

  • 如果不存在此类文件,则创建一个扩展名为.conf的空文件,并使用该新配置文件。

7

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

例子

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

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 转换之前)。 (从版本 4.2 开始可用

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

注意

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

例子

以下查询模板根据递归群组成员身份返回将{USER} 列为成员的所有群组。此 LDAP 查询假定群组对象通过使用 属性存储完整的用户标识名 (DN)member 来跟踪用户成员资格。查询包括 1.2.840.113556.1.4.1941LDAP_MATCHING_RULE_IN_CHAIN 的 AD 特定匹配规则 OID 。此匹配规则是 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 根据 创建 LDAPqueryTemplate {USER}查询,并用经过身份验证的用户名替换 令牌。 Active Directory 服务器对直接或间接将用户列为成员的任何群组执行递归群组查找。 AD Server 根据 Active Directory 群组 返回CN=dba,CN=Users,DC=example,DC=com 和 。CN=engineering,CN=Users,DC=example,DC=com

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

匹配规则LDAP_MATCHING_RULE_IN_CHAIN要求提供身份验证用户的完整标识名 。由于 Kerberos 要求使用用户的userPrincipalName 进行身份验证,因此您必须使用 将传入的用户名转换为 DN security.ldap.userToDNMapping。下一步将提供有关转换传入用户名以支持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 Server,并指定在此过程中创建的配置文件的路径。如果 MongoDB Server 当前正在运行,请做好停止服务器的准备。

Linux MongoDB Servers

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

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 角色或具有同等特权的自定义角色。

使用mongosh对 MongoDB Server 进行身份验证,设置以下选项:

例子

在此过程的前面,您在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 的setParameter authenticationMechanisms根据需要包含SCRAM-SHA-1和/或SCRAM-SHA-256

15

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

例子

以下操作创建以AD群组 标识名 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进行身份验证的用户授予PrimaryApplication数据库上的readWrite角色。

注意

要管理admin 数据库上的角色,您必须以在userAdmin adminuserAdminAnyDatabase 上具有 的用户身份或具有同等特权的自定义角色进行身份验证。

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,则必须在setParameter authenticationMechanisms配置选项中包含 SCRAM 身份验证机制(例如SCRAM-SHA-1和/或SCRAM-SHA-256 )。

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"

重要

The given sample configuration requires modification to match your AD schema, directory structure, and configuration. 您的部署可能还需要其他配置文件选项

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

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

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

mongokerberos 仅在 MongoDB Enterprise 中可用。

← Kerberos 身份验证故障排除