3.4版中的新功能:MongoDB Enterprise支持在LDAP服务器中查询经过身份验证的用户所属的LDAP组。MongoDB的每个返回组的专有名称(DN)映射到角色上的admin
数据库。MongoDB根据映射的角色及其关联的特权授权用户。有关更多信息,请参见
LDAP授权。
LDAP授权过程总结如下:
客户端连接到MongoDB并使用任何支持外部身份验证的身份验证机制 执行身份 验证。
在版本3.6.3中更改:要与$external
身份验证用户(即Kerberos,LDAP,x.509用户)一起使用会话,用户名不能大于10k字节。
MongoDB的结合到与指定的LDAP服务器security.ldap.servers
使用与指定的凭据security.ldap.bind.queryUser
和
security.ldap.bind.queryPassword
。
MongoDB默认使用简单绑定,但是sasl
如果在security.ldap.bind.method
和中
配置,则可以使用绑定security.ldap.bind.saslMechanisms
。
MongoDB使用构造一个LDAP查询
security.ldap.authz.queryTemplate
,并向LDAP服务器查询经过身份验证的用户的组成员身份。
MongoDB可以使用该security.ldap.userToDNMapping
选项来转换用户名以支持查询模板。
LDAP服务器评估查询并返回经过身份验证的用户所属的组的列表。
MongoDB通过将每个返回的组的专有名称(DN)映射到数据库中的角色,来授权用户在服务器上执行操作admin
。如果返回的组DN与admin
数据库上现有角色的名称完全匹配,则MongoDB会向用户授予角色和分配给该角色的特权。有关更多信息,请参阅
用于LDAP授权的MongoDB角色。
客户端可以在MongoDB服务器上执行要求授予已认证用户的角色或特权的操作。
按定义的时间间隔ldapUserCacheInvalidationInterval
,MongoDB刷新$external
缓存。在执行外部授权用户执行的后续操作之前,MongoDB从LDAP服务器重新获取其组成员身份。
LDAP的完整描述超出了本文档的范围。该页面假定您具有LDAP的先验知识。
本文档仅描述了MongoDB LDAP授权,并不替代LDAP上的其他资源。我们鼓励您在配置LDAP身份验证之前彻底熟悉LDAP及其相关主题。
MongoDB可以为您的MongoDB部署提供专业服务,以优化LDAP授权的配置。
从版本4.2.0开始,默认情况下,连接到LDAP服务器进行身份验证/授权时,MongoDB:
要更改连接池行为,请更新
ldapUseConnectionPool
参数。
libldap
和libldap_r
¶对于链接到的MongoDB 4.2(和4.0.9)企业二进制文件
libldap
(例如在RHEL上运行时),对的访问
libldap
是同步的,这会导致性能/延迟成本。
对于链接到的MongoDB 4.2(和4.0.9)企业二进制文件,与
libldap_r
早期MongoDB版本相比,行为没有变化。
使用LDAP授权,可以在LDAP服务器上进行用户创建和管理。MongoDB要求在
数据库上创建角色admin
,每个角色的名称必须与LDAP组专有名称(DN)完全匹配。这与MongoDB托管授权相反,后者需要在$external
数据库上创建用户。
要在MongoDB服务器上管理角色,请以用户身份进行身份验证,该用户的组成员资格与admin
具有角色管理特权(例如由提供的特权)的数据库角色相对应userAdmin
。创建或更新与LDAP组DN对应的角色,以使在该组中具有成员身份的用户获得适当的角色和特权。
例如,数据库管理员的LDAP组可能具有具有管理角色和特权的角色。用于市场营销或分析用户的LDAP组可能只对某些数据库具有读取特权。
重要
为相应的LDAP组配置角色时,请记住 该组中具有成员身份的所有用户都可以接收已配置的角色和特权。在配置MongoDB角色,LDAP组或组成员身份时,请考虑应用最小特权原则。
如果不存在具有角色管理特权的角色,并且不存在$external
具有这些特权的非用户,则您将无法执行用户管理,因为不能更改新的或现有的角色以反映对LDAP服务器上组或组成员资格的添加或更改。
要解决无法在MongoDB服务器上管理角色的情况,请执行以下过程:
admin
名称与相应的LDAP组专有名称相对应的数据库上创建一个角色。选择组DN时,请考虑哪个组最适合数据库管理。使用LDAP进行授权的MongoDB服务器使$external
数据库上的所有现有用户均
不可访问。如果$external
数据库中已有用户
,则必须满足$external
数据库上每个用户的以下要求,以确保继续访问:
admin
数据库中具有以用户的LDAP组命名的角色,因此,授予的角色和特权与授予非$external
用户的角色和特权相同。如果你想继续通过用户允许访问不上
$external
数据库,确保
authenticationMechanisms
参数包括
SCRAM-SHA-1
和/或SCRAM-SHA-256
适当的。或者,应用上面列出的要求将这些用户转换为LDAP授权。
您必须配置以下设置才能使用LDAP授权:
要通过操作系统库授权使用LDAP,指定以下设置为您的一部分mongod
或mongos
配置文件:
选项 | 描述 | 需要 |
---|---|---|
security.ldap.servers |
用引号括住的逗号分隔的LDAP服务器列表host[:port]
。 |
是 |
security.ldap.authz.queryTemplate |
MongoDB执行的RFC4515和RFC4516 LDAP格式的查询URL模板,以获取用户所属的LDAP组。该查询相对于中指定的一个或多个主机 您可以在模板中使用以下标记:
|
是 |
security.ldap.bind.queryUser |
当连接到LDAP服务器并在其上执行操作和查询时,MongoDB服务器绑定的身份。 与一起使用 指定的用户必须具有适当的特权才能支持从configure生成的LDAP查询
|
是 |
security.ldap.bind.queryPassword |
使用时用于绑定到LDAP服务器的密码
queryUser 。 |
是 |
security.ldap.bind.method |
用于指定 默认为 |
否,除非sasl 用于绑定到LDAP服务器。 |
security.ldap.bind.saslMechanisms |
用于指定SASL机制, 默认为 |
否,除非设置bindMethod 为
,否则sasl 您需要其他或其他SASL机制。 |
security.ldap.bind.useOSDefaults |
MongoDB中的Windows部署可以代替使用操作系统凭证queryUser 和
queryPassword 用于认证或连接到LDAP服务器时具有约束力。 |
不,除非更换queryUser 和
queryPassword 。 |
security.ldap.userToDNMapping |
根据您queryTemplate 的身份,经过身份验证的客户端用户名可能需要转换以支持LDAP查询URL。userToDNMapping 允许MongoDB转换传入的用户名。 |
否,除非客户端用户名需要转换为LDAP DN。 |
MongoDB使用security.ldap.authz.queryTemplate
来创建
RFC4516格式的LDAP查询URL。在模板中,您可以使用以下任一方法:
{USER}
占位符以将经过身份验证的用户名替换为LDAP查询URL。如果MongoDB使用转换了用户名
userToDNMapping
,则MongoDB {USER}
在构造LDAP查询URL时将令牌替换
为转换后的用户名。{PROVIDED_USER}
占位符,以将提供的用户名(即在身份验证或LDAP转换之前)替换为LDAP查询。设计查询模板以检索用户的组。
例
以下查询模板返回LDAP用户对象的memberOf
属性中列出的所有组。该查询假定memberOf
属性存在-您的特定LDAP部署可能使用其他属性或方法来跟踪组成员身份。此查询还假定用户使用其完整LDAP DN作为用户名进行身份验证。
LDAP查询URL必须符合RFC4516中定义的格式:
考虑一下RFC4516中引用的每个组件的定义:
The ``dn`` is an LDAP Distinguished Name using the string format described
in `RFC4514 <https://tools.ietf.org/html/rfc4514>`_. It identifies the base
object of the LDAP search or the target of a non-search operation.
The ``attributes`` construct is used to indicate which attributes should be
returned from the entry or entries.
The ``scope`` construct is used to specify the scope of the search to perform
in the given LDAP server. The allowable scopes are "base" for a base object
search, "one" for a one-level search, or "sub" for a subtree search.
The ``filter`` is used to specify the search filter to apply to entries
within the specified scope during the search. It has the format specified
in [RFC4515].
The ``extensions`` construct provides the LDAP URL with an extensibility
mechanism, allowing the capabilities of the URL to be extended in the
future.
如果查询包含attribute
,则MongoDB假定查询检索到该实体所属的DN。
如果查询不包含属性,则MongoDB假定查询检索用户所属的所有实体。
MongoDB当前忽略LDAP查询中指定的任何扩展名。
重要
RFC4516或LDAP查询URL构造的完整描述超出了本文档的范围。
以下教程包含通过操作系统LDAP库连接到LDAP服务器的过程:
使用LDAP进行授权时,通过mongo
外壳连接的用户必须:
设置--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服务器进行身份验证:
如果未在-password
命令行选项中指定密码,则mongo
Shell会提示您输入密码。
重要
该$external
参数必须放在单引号中,而不是双引号中,以防止外壳程序解释$external
为变量。
MongoDB将LDAP返回的每个返回的组专有名称(DN)映射query
到
数据库上的角色admin
。
如果MongoDB获取其DN 与现有角色的名称完全匹配的组,则MongoDB会授予经过身份验证的用户角色和 与该角色关联的特权。如果MongoDB无法将任何返回的组映射到角色,则MongoDB不会向用户授予任何特权。
注意
LDAP和 kerberos
身份验证通常需要在$external
数据库中创建用户。如果还使用LDAP授权,你就不会需要在创建用户$external
数据库。您只需要在admin
数据库中创建适当的角色。用户仍然针对$external
数据库进行身份验证。
重要
如果您使用LDAP进行授权,并且LDAP组DN包含RFC4514转义序列,则您在admin
数据库中创建的角色也必须遵循RFC4514进行转义。
例
数据库在admin
数据库上配置了以下角色:
alice@dba.example.com
根据$external
数据库对用户进行
身份验证后,MongoDB服务器将执行从配置中派生的查询,以检索包含已身份验证用户作为成员的组。在此示例中,MongoDB服务器为用户检索以下组DN:query template
MongoDB将这些组DN映射到admin
数据库上的角色。第一组DN匹配第一个角色,MongoDB授予经过身份验证的用户其角色和特权。第二个组DN与服务器上的任何角色都不匹配,因此MongoDB不授予任何其他权限。
新用户bob@analytics.example.com
对$external
数据库进行身份验证
。MongoDB服务器使用查询模板中提供的用户名重复查询过程。在此示例中,MongoDB服务器为用户检索以下组DN:
MongoDB将这些组DN映射到admin
数据库上的角色,并向经过身份验证的用户授予第二个角色的角色和特权。
新用户workstation@guest.example.com
对$external
数据库进行身份验证
。MongoDB服务器使用查询模板中提供的用户名重复查询过程。在此示例中,MongoDB服务器为用户检索以下组DN:
MongoDB将组映射到admin
数据库上的角色,并且由于不存在匹配的角色,因此不会向用户授予其他权限。