Docs 菜单

通过原生 LDAP 使用自管理 Active Directory 对用户进行身份验证和授权

MongoDB Enterprise通过平台LDAP库为针对指定轻量级目录访问协议 ( LDAP ) 服务(例如 Active Directory (AD))的代理身份验证和授权请求提供支持。

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

注意

对于与 libldap 链接的 MongoDB 4.2 企业版二进制文件(例如在 RHEL 上运行时),对 libldap 的访问是同步进行的,会产生一些性能/延迟成本。

对于链接到 libldap_r MongoDB 4.2 Enterprise 二进制文件,与早期 MongoDB 版本相比,行为没有变化。

重要

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

AD的完整描述超出了本教程的范围。 本教程假定您已了解AD

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

必须先配置内部成员身份验证,然后才能为集群设置 LDAP 身份验证或授权。

本教程介绍如何配置 MongoDB 以进行AD身份验证和授权。

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

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

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

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

要对 $external 身份验证用户(Kerberos、LDAP 或 X.509 用户)使用客户端会话和因果一致性保证,用户名不能大于 10k 字节。

本教程使用以下示例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 的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

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

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

如果 MongoDB 服务器目前强制执行身份验证,则必须以具有角色管理权限(如 userAdminuserAdminAnyDatabase 提供的权限)的用户身份验证 admin 数据库。为 MongoDB 服务器配置的身份验证机制纳入适当的 --authenticationMechanism

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

注意

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

3

要托管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 群组或群组成员身份时。

4

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

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

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

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

5

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

您还必须通过将security.authorization设置为enabled并将setParameter authenticationMechanisms设置为PLAIN来启用 LDAP 身份验证

例子

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

security:
authorization: "enabled"
ldap:
servers: "activedirectory.example.net"
setParameter:
authenticationMechanisms: 'PLAIN'

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

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

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

6

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

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

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

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

注意

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

例子

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

警告

如果AD林包含大量群组,则递归member:1.2.840.113556.1.4.1941过滤可能会导致性能显着下降。

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=com

  • CN=engineering,CN=Users,DC=example,DC=com

  • CN=PrimaryApplication,CN=Users,DC=example,DC=com

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

匹配规则LDAP_MATCHING_RULE_IN_CHAIN要求提供身份验证用户的完整标识名 。如果用户使用不同的用户名格式(例如user principal name )进行身份验证,则必须使用 将传入的用户名转换为 DN security.ldap.userToDNMapping

7

如果用户使用非完整 LDAP DN 的用户名进行身份验证,您可能需要转换用户名以支持 LDAP 身份验证或授权。 MongoDB 使用转换后的用户名进行身份验证和授权。

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

例子

根据已配置的queryTemplate ,用户必须使用其完整的 LDAP 标识名进行身份验证。如果用户使用其userPrincipalName进行身份验证,则必须进行转换,将提供的用户名转换为完整的 LDAP DN。

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

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

Active Directory 服务器返回与具有匹配userPrincipalName的用户对象关联的完整 LDAP DN。 然后,MongoDB 可以使用此转换后的用户名进行身份验证授权。

您必须修改给定的示例配置以匹配您的部署。 例如, 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} 令牌。

重要

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

8

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

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

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

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

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

9

添加部署所需的任何其他配置选项。 例如,您可以指定所需的storage.dbPath或更改默认的net.port数字。

mongodmongos默认绑定到本地主机。 如果部署的成员在不同主机上运行,或者希望远程客户端连接到部署,则必须指定net.bindIp设置。

10

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

mongod --config <path-to-config-file>

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

11

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

使用 mongosh 对 MongoDB 服务器进行身份验证,并设置以下选项:

例子

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

mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanism 'PLAIN' --authenticationDatabase '$external' --host <hostname> --port <port>

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

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

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

注意

如果希望以现有的非 $external 用户身份进行身份验证,请将 --authenticationMechanism 设置为 SCRAM 身份验证机制(例如,视情况设为 SCRAM-SHA-1SCRAM-SHA-256)。这要求 MongoDB 服务器的 setParameter authenticationMechanisms 包括 SCRAM-SHA-1 和/或 SCRAM-SHA-256

12

对于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 数据库上的角色,您必须以拥有以下权限的用户身份进行身份验证:admin 上的 userAdminuserAdminAnyDatabase,或具有同等权限的自定义角色。

13

如果使用在$external数据库上配置的用户升级现有安装,则必须满足每个用户的以下要求,以确保在为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: "PLAIN,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: "PLAIN"

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

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