文档菜单
文档首页
/
MongoDB 手册
/ / /

自管理部署上的LDAP授权

本页内容

  • 注意事项
  • 配置
  • 教程
  • 使用LDAP授权连接到MongoDB服务器
  • MongoDB的LDAP授权角色

注意

从MongoDB 8.0开始,LDAP身份验证和授权已弃用。LDAP仍然可用,MongoDB 8.0的生命周期内将继续以不变的方式运行。LDAP将在未来的主要版本中删除。

有关详细信息,请参阅LDAP 弃用.

MongoDB企业版支持查询LDAP服务器以获取认证用户所属的LDAP组。MongoDB将每个返回组的区分名称(DN)映射到admin数据库中的角色。MongoDB根据映射的角色及其相关权限授权用户。有关更多信息,请参阅LDAP授权

以下是对LDAP授权过程的总结

  1. 客户端连接到MongoDB并使用任何支持外部身份验证的认证机制进行认证。

    为了与使用客户端会话和因果一致性保证$external认证用户(Kerberos、LDAP或x.509用户)一起使用,用户名不能超过10k字节。

  2. MongoDB使用security.ldap.servers指定的凭据通过security.ldap.bind.queryUsersecurity.ldap.bind.queryPassword指定的凭据绑定到指定的LDAP服务器。

    MongoDB默认使用简单绑定,但如果在security.ldap.bind.methodsecurity.ldap.bind.saslMechanisms中配置,则可以使用sasl绑定。

  3. MongoDB使用security.ldap.authz.queryTemplate构建LDAP查询,并查询LDAP服务器以获取认证用户的组成员资格。

    MongoDB可以使用security.ldap.userToDNMapping选项转换用户名以支持查询模板。

  4. LDAP服务器评估查询并返回认证用户所属的组列表。

  5. MongoDB通过将每个返回组的区分名称(DN)映射到admin数据库中的一个角色来授权用户在服务器上执行操作。如果返回的组DN与admin数据库中现有角色的名称完全匹配,MongoDB将授予用户该角色分配的角色和权限。有关更多信息,请参阅MongoDB的LDAP授权角色

  6. 客户端可以在MongoDB服务器上执行需要授予认证用户的角色或权限的操作。

  7. 在由 ldapUserCacheInvalidationInterval 定义的时间间隔内,MongoDB 清除 $external 缓存。在执行外部授权用户后续操作之前,MongoDB 会从 LDAP 服务器重新获取他们的组成员资格。

LDAP 的详细描述超出了本文档的范围。本页假定您已具备 LDAP 的相关知识。

本文档仅描述 MongoDB LDAP 授权,并不替代其他关于 LDAP 的资源。我们鼓励您在配置 LDAP 认证之前,彻底熟悉 LDAP 及其相关主题。

MongoDB 可以为您的 MongoDB 部署提供最佳配置的 LDAP 授权的 专业服务

MongoDB 支持以下认证方法的 LDAP 授权

在此配置下,MongoDB 使用 LDAP、X.509 或 Kerberos 授权来验证客户端连接。

当连接到LDAP服务器进行身份验证/授权时,MongoDB默认

  • 如果在Windows或

    • Linux上运行,将使用连接池

    • (其中MongoDB企业版二进制文件链接到libldap_r。

  • 如果在Linux上运行且MongoDB企业版二进制文件链接到libldap。),则不会使用连接池

要更改连接池行为,请更新ldapUseConnectionPool参数。

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

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

使用LDAP授权时,用户创建和管理发生在LDAP服务器上。MongoDB需要在admin数据库上创建roles,每个角色的名称必须与LDAP组区分名(DN)完全匹配。这与MongoDB管理的授权不同,MongoDB管理的授权需要在$external数据库上创建用户。

为了管理MongoDB服务器上的角色,请以具有对应于具有角色管理权限的admin数据库角色的用户身份进行认证,例如由userAdmin提供的那些。创建或更新与LDAP组DN对应的角色,以便具有该组成员资格的用户能够获得适当的角色和权限。

例如,数据库管理员可能有一个具有管理角色和权限的角色。营销或分析用户可能有一个只在某些数据库上具有读取权限的角色。

重要

在为相应的LDAP组配置角色时,请记住,该组中的所有用户都可以接收配置的角色和权限。在配置MongoDB角色、LDAP组或组成员资格时,请考虑应用最小权限原则。

如果不存在具有角色管理权限的角色,并且不存在具有这些权限的非$external用户,您实际上无法执行用户管理,因为无法更改新角色或现有角色以反映LDAP服务器上组或组成员资格的增加或更改。

要纠正无法在MongoDB服务器上管理角色的场景,请执行以下步骤

  1. 以无认证和LDAP授权的方式重启MongoDB服务器

  2. admin数据库上创建一个与适当的LDAP组全称名称相对应的角色。在选择组DN时,请考虑哪个组最适合数据库管理。

  3. 以认证和LDAP授权的方式重启MongoDB服务器

  4. 以具有对应创建的管理角色的组成员资格的用户身份进行认证。

使用LDAP进行授权的MongoDB服务器使$external数据库上的任何现有用户都无法访问。如果$external数据库中存在现有用户,您必须满足以下要求,以确保每个用户的持续访问

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

  • 用户对象属于适当的LDAP组

  • MongoDB在名为用户LDAP组的admin数据库上有角色,这样授予的角色和权限与授予非$external用户的权限相同。

如果您想继续允许不在$external数据库上的用户访问,请确保authenticationMechanisms参数包括SCRAM-SHA-1和/或SCRAM-SHA-256。或者,可以将这些用户过渡到LDAP授权,并应用上述要求。

对于副本集,首先在次要仲裁者成员上配置LDAP授权,然后再配置主要成员。这也适用于分片副本集配置服务器副本集。一次配置一个副本集成员,以保持成员的多数写可用性。

分片集群中,您必须在集群级别的用户上配置配置服务器上的LDAP授权。您可以选择为分片上的本地用户配置LDAP授权。

必须配置以下设置才能使用 LDAP 授权

要通过操作系统库使用 LDAP 进行授权,请在您的 mongodmongos 配置文件中指定以下设置

选项
描述
必需

以引号括起来的逗号分隔的 LDAP 服务器列表,格式为 host[:port]

您可以使用 srv:srv_raw: 作为 LDAP 服务器的前缀。

如果您的连接字符串指定为 "srv:<DNS_NAME>"mongod 将验证 "_ldap._tcp.gc._msdcs.<DNS_NAME>" 存在于 SRV 以支持 Active Directory。如果未找到,mongod 将验证 "_ldap._tcp.<DNS_NAME>" 存在于 SRV。如果找不到 SRV 记录,mongod 将警告您使用 "srv_raw:<DNS_NAME>" 代替。

如果您的连接字符串指定为 "srv_raw:<DNS_NAME>"mongod 将对 "<DNS NAME>" 执行 SRV 记录查找。

由MongoDB执行以获取用户所属的LDAP组的LDAP格式查询URL模板。该查询相对于在servers中指定的主机或主机。

您可以在模板中使用以下标记

  • {USER}
    将认证的用户名或转换后的用户名替换为LDAP查询。
  • {PROVIDED_USER}
    将提供的用户名(即在认证或LDAP转换之前)替换为LDAP查询。

只有mongod支持此参数。mongos将根据其配置在配置服务器上的设置进行委托。

当连接到并执行LDAP服务器上的操作和查询时,MongoDB服务器绑定的标识。

queryPassword一起使用。

指定的用户必须具有支持从配置的queryTemplate生成的LDAP查询的相应权限。

在通过queryUser绑定到LDAP服务器时使用的密码。

用于指定 mongodmongos 用于认证或绑定到 LDAP 服务器的方 法。指定 sasl 以使用在 security.ldap.bind.saslMechanisms 中定义的 SASL 协议之一。

默认值为 simple

不适用,除非使用 sasl 绑定到 LDAP 服务器。

用于指定 mongodmongos 在认证或绑定到 LDAP 服务器时可以使用的 SASL 机制。MongoDB 和 LDAP 服务器必须至少就一个 SASL 机制达成一致。

默认值为 DIGEST-MD5

不适用,除非将 method 设置为 sasl,并且需要不同或额外的 SASL 机制。
Windows MongoDB 部署可以使用操作系统的凭据来替代 queryUserqueryPassword 以进行认证或绑定,就像连接到 LDAP 服务器时一样。
不适用,除非替换 queryUserqueryPassword
根据您的 queryTemplate,认证客户端用户名可能需要转换以支持 LDAP 查询 URL。 userToDNMapping 允许 MongoDB 转换传入的用户名。
不适用,除非客户端用户名需要转换为 LDAP DNs。

当您配置了 LDAP 授权后,重新启动 mongodmongos。服务器现在使用 LDAP 授权(X.509、Kerberos 或 LDAP)来认证客户端连接。

MongoDB使用security.ldap.authz.queryTemplate来创建一个RFC4516格式的LDAP查询URL。在模板中,您可以使用以下任意一个:

  • {USER}占位符将认证的用户名替换到LDAP查询URL中。如果MongoDB使用userToDNMapping转换了用户名,MongoDB会在构建LDAP查询URL时将{USER}令牌替换为转换后的用户名。

  • {PROVIDED_USER}占位符将提供的用户名替换到LDAP查询中,即在认证或LDAP转换之前。

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

示例

以下查询模板返回LDAP用户对象中memberOf属性列出的任何组。此查询假设memberOf属性存在 - 您特定的LDAP部署可能使用不同的属性或方法来跟踪组成员资格。此查询还假设用户使用他们的完整LDAP DN作为用户名进行认证。

"{USER}?memberOf?base"

LDAP查询URL必须符合在RFC4516中定义的格式。

[ dn [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

以下内容引用自RFC4516中对各个组件的定义

dn是一个LDAP唯一名称,使用在RFC4514中描述的字符串格式。它标识了LDAP搜索的基对象或非搜索操作的目标。

attributes构造用于指示应从条目或条目中返回哪些属性。

scope构造用于指定在给定的LDAP服务器上执行搜索的范围。允许的搜索范围有“base”(基对象搜索)、“one”(单级搜索)或“sub”(子树搜索)。

filter用于指定在搜索过程中应应用到指定范围内条目的搜索过滤器。它具有[RFC4515]中指定的格式。

extensions构造为LDAP URL提供了一个可扩展机制,允许将来扩展URL的功能。

如果查询包含attribute,MongoDB假定查询检索此实体是成员的DN。

如果查询不包含属性,MongoDB假定查询检索用户是成员的所有实体。

MongoDB目前忽略LDAP查询中指定的任何扩展。

重要

RFC4516或LDAP查询URL构造的完整描述超出了本文档的范围。

以下教程包含通过操作系统LDAP库连接到LDAP服务器的步骤

当使用LDAP进行授权时,通过mongosh连接的用户必须

包括 MongoDB 服务器的 --host--port,以及与您的部署相关的任何其他选项。

例如,以下操作用于对运行 LDAP 认证和授权的 MongoDB 服务器进行身份验证

mongosh --username alice@dba.example.com --password --authenticationDatabase '$external' --authenticationMechanism "PLAIN" --host "mongodb.example.com" --port 27017

如果您未指定 --password 命令行选项的密码,则 mongosh 会提示输入密码。

重要

为了防止 shell 将 $external 解释为变量,$external 参数必须放在单引号内,而不是双引号。

MongoDB 将 LDAP 查询 返回的每个返回的组区分名称(DN)映射到 admin 数据库上的一个 角色

如果 MongoDB 获取的组 DN 正好 与现有角色的名称匹配,MongoDB 将授予认证用户与该角色关联的角色和 权限。如果 MongoDB 无法将返回的任何组映射到角色,MongoDB 将不会向用户授予任何权限。

注意

LDAPKerberos 认证通常需要在 $external 数据库中创建用户。如果您还使用 LDAP 进行授权,则不需要在 $external 数据库中创建用户。您只需在 admin 数据库中创建相应的角色。用户仍然会针对 $external 数据库进行身份验证。

重要

如果您使用 LDAP 进行授权且您的 LDAP 组 DNs 包含 RFC4514 转义序列,则您在 admin 数据库中创建的角色也必须遵循 RFC4514 进行转义。

示例

数据库在 admin 数据库上配置了以下角色

{
role: "CN=dba,CN=Users,DC=example,DC=com",
privileges: [],
roles: [ "dbAdminAnyDatabase", "clusterAdmin" ]
}
{
role: "CN=analytics,CN=Users,DC=example,DC=com"
privileges: [],
roles: [
{ role : "read", db : "web_statistics" },
{ role : "read", db : "user_statistics" }
]
}

在将用户 alice@dba.example.com 验证为 $external 数据库后,MongoDB 服务器执行一个由配置的 查询模板 衍生的查询,以检索包括已验证用户作为成员的组。在此示例中,MongoDB 服务器检索以下用户组 DNs

dn:CN=dba,CN=Users,dc=example,dc=com
dn:CN=admin,CN=Users,dc=example,dc=com

MongoDB 将这些组 DNs 映射到 admin 数据库上的角色。第一个组 DNs 与第一个角色匹配,MongoDB 授予已验证用户其角色和权限。第二个组 DNs 不与服务器上的任何角色匹配,因此 MongoDB 不授予额外的权限。

新用户 bob@analytics.example.com 验证为 {"@context":"https://schema.org","@type":"SoftwareSourceCode","codeSampleType":"code snippet","text":"dn:cn=analytics,CN=Users,dc=example,dc=com"}

dn:cn=analytics,CN=Users,dc=example,dc=com

MongoDB 将这些组 DNs 映射到 admin 数据库上的角色,并授予已验证用户第二个角色的角色和权限。

新用户 workstation@guest.example.com 验证为 {"@context":"https://schema.org","@type":"SoftwareSourceCode","codeSampleType":"code snippet","text":"dn:cn=guest,CN=Users,dc=example,dc=com"}

dn:cn=guest,CN=Users,dc=example,dc=com

MongoDB 将组映射到 admin 数据库的角色上,由于没有匹配的角色存在,因此授予用户没有额外的权限。

返回

集合级别访问