自管理部署上的LDAP授权
注意
从MongoDB 8.0开始,LDAP身份验证和授权已弃用。LDAP仍然可用,MongoDB 8.0的生命周期内将继续以不变的方式运行。LDAP将在未来的主要版本中删除。
有关详细信息,请参阅LDAP 弃用.
MongoDB企业版支持查询LDAP服务器以获取认证用户所属的LDAP组。MongoDB将每个返回组的区分名称(DN)映射到admin
数据库中的角色。MongoDB根据映射的角色及其相关权限授权用户。有关更多信息,请参阅LDAP授权。
以下是对LDAP授权过程的总结
客户端连接到MongoDB并使用任何支持外部身份验证的认证机制进行认证。
为了与使用客户端会话和因果一致性保证的
$external
认证用户(Kerberos、LDAP或x.509用户)一起使用,用户名不能超过10k字节。MongoDB使用
security.ldap.servers
指定的凭据通过security.ldap.bind.queryUser
和security.ldap.bind.queryPassword
指定的凭据绑定到指定的LDAP服务器。MongoDB默认使用简单绑定,但如果在
security.ldap.bind.method
和security.ldap.bind.saslMechanisms
中配置,则可以使用sasl
绑定。MongoDB使用
security.ldap.authz.queryTemplate
构建LDAP查询,并查询LDAP服务器以获取认证用户的组成员资格。MongoDB可以使用
security.ldap.userToDNMapping
选项转换用户名以支持查询模板。LDAP服务器评估查询并返回认证用户所属的组列表。
MongoDB通过将每个返回组的区分名称(DN)映射到
admin
数据库中的一个角色来授权用户在服务器上执行操作。如果返回的组DN与admin
数据库中现有角色的名称完全匹配,MongoDB将授予用户该角色分配的角色和权限。有关更多信息,请参阅MongoDB的LDAP授权角色。客户端可以在MongoDB服务器上执行需要授予认证用户的角色或权限的操作。
在由
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
和libldap_r
对于链接到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服务器上管理角色的场景,请执行以下步骤
以无认证和LDAP授权的方式重启MongoDB服务器
在
admin
数据库上创建一个与适当的LDAP组全称名称相对应的角色。在选择组DN时,请考虑哪个组最适合数据库管理。以认证和LDAP授权的方式重启MongoDB服务器
以具有对应创建的管理角色的组成员资格的用户身份进行认证。
现有用户
使用LDAP进行授权的MongoDB服务器使$external
数据库上的任何现有用户都无法访问。如果$external
数据库中存在现有用户,您必须满足以下要求,以确保每个用户的持续访问
用户在LDAP服务器上有相应的用户对象
用户对象属于适当的LDAP组
MongoDB在名为用户LDAP组的
admin
数据库上有角色,这样授予的角色和权限与授予非$external
用户的权限相同。
如果您想继续允许不在$external
数据库上的用户访问,请确保authenticationMechanisms
参数包括SCRAM-SHA-1
和/或SCRAM-SHA-256
。或者,可以将这些用户过渡到LDAP授权,并应用上述要求。
副本集
对于副本集,首先在次要和仲裁者成员上配置LDAP授权,然后再配置主要成员。这也适用于分片副本集或配置服务器副本集。一次配置一个副本集成员,以保持成员的多数写可用性。
分片集群
配置
必须配置以下设置才能使用 LDAP 授权
要通过操作系统库使用 LDAP 进行授权,请在您的 mongod
或 mongos
配置文件中指定以下设置
选项 | 描述 | 必需 |
---|---|---|
以引号括起来的逗号分隔的 LDAP 服务器列表,格式为 您可以使用 如果您的连接字符串指定为 如果您的连接字符串指定为 | 是 | |
是 | ||
当连接到并执行LDAP服务器上的操作和查询时,MongoDB服务器绑定的标识。 与 指定的用户必须具有支持从配置的 | 是 | |
在通过 queryUser 。绑定到LDAP服务器时使用的密码。 | 是 | |
用于指定 默认值为 | 不适用,除非使用 sasl 绑定到 LDAP 服务器。 | |
不适用,除非将 method 设置为 sasl ,并且需要不同或额外的 SASL 机制。 | ||
Windows MongoDB 部署可以使用操作系统的凭据来替代 queryUser 和 queryPassword 以进行认证或绑定,就像连接到 LDAP 服务器时一样。 | 不适用,除非替换 queryUser 和 queryPassword 。 | |
根据您的 queryTemplate ,认证客户端用户名可能需要转换以支持 LDAP 查询 URL。 userToDNMapping 允许 MongoDB 转换传入的用户名。 | 不适用,除非客户端用户名需要转换为 LDAP DNs。 |
当您配置了 LDAP 授权后,重新启动 mongod
或 mongos
。服务器现在使用 LDAP 授权(X.509、Kerberos 或 LDAP)来认证客户端连接。
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授权连接到MongoDB服务器
当使用LDAP进行授权时,通过mongosh
连接的用户必须
将
--authenticationDatabase
设置为$external
。将
--authenticationMechanism
设置为适当的身份验证机制。如果使用LDAP身份验证,则将其设置为
PLAIN
。如果使用Kerberos身份验证,则将其设置为
GSSAPI
。如果使用x.509,则将其设置为
MONGODB-X.509
。将
--username
设置为符合security.ldap.authz.queryTemplate
或任何配置的security.ldap.userToDNMapping
模板的用户名。将
--password
设置为相应的密码。
包括 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 授权的角色
MongoDB 将 LDAP 查询
返回的每个返回的组区分名称(DN)映射到 admin
数据库上的一个 角色。
如果 MongoDB 获取的组 DN 正好 与现有角色的名称匹配,MongoDB 将授予认证用户与该角色关联的角色和 权限。如果 MongoDB 无法将返回的任何组映射到角色,MongoDB 将不会向用户授予任何权限。
注意
重要
如果您使用 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 不授予额外的权限。
新用户 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 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 admin
数据库的角色上,由于没有匹配的角色存在,因此授予用户没有额外的权限。