注意
从MongoDB 8.0开始, LDAP身份验证和授权已弃用。 LDAP可用并将在MongoDB 8的整个生命周期内继续运行而不进行更改。 LDAP将在未来的主要发布中删除。
有关详细信息,请参阅 LDAP 弃用。
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 服务器和AD之间进行绑定。 SASL、SASL 机制或给定 SASL 机制的特定AD配置要求的完整描述超出了本教程的范围。 本教程假定您已了解 SASL 及其相关主题。
配置内部成员身份验证
必须先配置内部成员身份验证,然后才能为集群设置 LDAP 身份验证或授权。
Considerations
本教程介绍如何配置 MongoDB 以进行AD身份验证和授权。
要在自己的 MongoDB Server 上执行此过程,您必须根据自己的特定基础架构,尤其是 Active 目录 配置、构建AD查询或管理用户,修改给定的过程。
传输层安全
默认情况下,MongoDB 在绑定到 AD 服务器时会创建 TLS/SSL 连接。这需要配置 MongoDB 服务器的主机,使其能够访问 AD 服务器的证书颁发机构 (CA) 证书。
本教程提供所需主机配置的说明。
本教程假设您可以访问 AD 服务器的 CA 证书,并可以在 MongoDB 服务器上创建证书副本。
用户名
要对 $external 身份验证用户(Kerberos、LDAP 或 X.509 用户)使用客户端会话和因果一致性保证,用户名不能大于 10k 字节。
Active Directory 模式示例
本教程使用以下示例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
Active Directory 凭证
本教程使用用户名和密码在AD服务器上执行查询。 提供的凭证必须在 AD服务器上具有足够的特权,以支持与security.ldap.userToDNMapping或security.ldap.authz.queryTemplate相关的查询。
副本集
MongoDB LDAP 授权要求副本集中的每个 mongod 至少使用 MongoDB 3.4.0或更高版本。
分片集群
MongoDB LDAP 授权要求分片集群中的每一个 mongod 和 mongos 都至少使用 MongoDB 3.4.0 或更高版本。
步骤
为运行 MongoDB 的服务器配置 TLS/SSL
要通过 TLS/SSL 连接到AD (AD)服务器, mongod或mongos需要访问权限AD服务器的证书颁发机构 (CA) 证书。
在 Linux 上,通过 ldap.conf 文件中的 TLS_CACERT 或 TLS_CACERTDIR 选项指定 AD 服务器的 CA 证书。
平台的包管理器在安装 MongoDB Enterprise 的libldap 依赖项时创建 ldap.conf 文件。有关配置文件或引用选项的完整文档,请参阅 ldap .conf。
在Microsoft Windows上,使用平台的档案管理工具加载AD服务器的证书颁发机构 (CA) 证书。 确切的档案管理工具取决于Windows版本。 要使用该工具,请参阅适用于您的Windows版本的文档。
如果mongod或mongos无法访问权限AD CA 文件,则他们无法创建与 Active Directory服务器的 TLS/SSL 连接。
或者,将 security.ldap.transportSecurity 设置为 none 以禁用 TLS/SSL。
警告
将 transportSecurity 设置为 none 可在 MongoDB 和 AD 服务器之间传输明文信息,包括用户凭证。
连接到 MongoDB Server。
使用 mongosh 用 --host 和 --port 选项连接 MongoDB 服务器。
mongosh --host <hostname> --port <port>
如果 MongoDB 服务器目前强制执行身份验证,则必须以具有角色管理权限(如 userAdmin 或 userAdminAnyDatabase 提供的权限)的用户身份验证 admin 数据库。为 MongoDB 服务器配置的身份验证机制纳入适当的 --authenticationMechanism。
mongosh --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"
创建用户管理角色。
要使用AD管理MongoDB用户,您需要在可以创建和管理角色的admin数据库上创建至少一个角色,例如userAdmin或userAdminAnyDatabase提供的角色。
角色的名称必须与 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 配置文件。
MongoDB 配置文件是具有 .conf 文件扩展名的纯文本 YAML 文件。
如果您正在升级现有的 MongoDB 部署,请复制当前配置文件并从该副本开始工作。
(仅限 Linux)如果这是新部署,并且您使用了平台的包管理器来安装 MongoDB Enterprise,则该安装将包含
/etc/mongod.conf默认配置文件。使用该默认配置文件,或复制该文件以供使用。如果不存在此类文件,请创建一个扩展名为
.conf的空文件,然后从该新配置文件进行操作。
配置 MongoDB 以连接到 Active Directory。
在 MongoDB 配置文件中,将 security.ldap.servers 设置为 AD 服务器的主机和端口。如果您的 AD 基础结构包含多个用于复制的 AD 服务器,请将服务器的主机和端口以逗号分隔的列表形式指定为 security.ldap.servers。
您还必须通过将security.authorization设置为enabled并将setParameter authenticationMechanisms设置为PLAIN来启用 LDAP 身份验证
例子
要连接到位于 activedirectory.example.net 的 AD 服务器,请在配置文件中包含以下内容:
security: authorization: "enabled" ldap: servers: "activedirectory.example.net" setParameter: authenticationMechanisms: 'PLAIN'
MongoDB必须绑定到AD服务器才能执行查询。 默认, MongoDB使用简单身份验证机制将自身绑定到AD服务器。
或者,您可以在配置文件中配置以下设置以使用 SASL 绑定到 AD 服务器:
将
security.ldap.bind.method设置为sasl。security.ldap.bind.saslMechanisms,指定一个字符串,表示 AD 服务器支持的以逗号分隔的 SASL 机制。
本教程使用默认的 simple LDAP 身份验证机制。
为授权配置 LDAP 查询模板。
在 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 。此匹配规则是LDAP搜索筛选器的特定于 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=comCN=engineering,CN=Users,DC=example,DC=comCN=PrimaryApplication,CN=Users,DC=example,DC=com
MongoDB 将每个返回的组标识名映射到 admin 数据库上的一个角色。对于每个映射组标识名,如果 admin 数据库中存在名称与标识名完全匹配的现有角色,MongoDB 就会向用户授予分配给该角色的角色和权限。
匹配规则LDAP_MATCHING_RULE_IN_CHAIN要求提供身份验证用户的完整标识名 。如果用户使用不同的用户名格式(例如user
principal name )进行身份验证,则必须使用 将传入的用户名转换为 DN security.ldap.userToDNMapping。
可选:转换传入的用户名,以便通过 Active Directory 进行身份验证,
如果用户使用非完整 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} 令牌。
重要
如果使用 userToDNMapping 的 substitution 参数来转换群组名称,则替换的结果必须是 RFC4514 转义字符串。
配置查询凭证。
MongoDB 需要凭证才能在 AD 服务器上执行查询。
在配置文件中配置以下设置:
security.ldap.bind.queryUser,指定mongod或mongos绑定的 Active 目录 用户,以便在AD服务器上执行查询。security.ldap.bind.queryPassword,为指定的queryUser指定密码。
security: ldap: bind: queryUser: "mongodbadmin@dba.example.com" queryPassword: "secret123"
在Windows MongoDB服务器上,您可以设立security.ldap.bind.useOSDefaults设置为true以使用凭证用户的档案,而不是queryUser和queryPassword 。
queryUser 必须具有代表 MongoDB 执行所有 LDAP 查询的权限。
可选:添加其他配置设置。
添加部署所需的任何其他配置选项。 例如,您可以指定所需的storage.dbPath或更改默认的net.port数字。
mongod和mongos默认绑定到本地主机。 如果部署的成员在不同主机上运行,或者希望远程客户端连接到部署,则必须指定net.bindIp设置。
使用 Active Directory 身份验证和授权启动 MongoDB Server。
使用 --config 选项启动 MongoDB 服务器,并指定在此过程中创建的配置文件的路径。如果 MongoDB 服务器当前正在运行,请做好适当的准备以停止服务器。
mongod --config <path-to-config-file>
Windows MongoDB 部署必须使用mongod.exe而不是mongod 。
连接到 MongoDB Server。
连接到 MongoDB 服务器,以特定用户身份进行身份验证,该用户的直接或可传递群组成员身份对应于 admin 数据库上具有 userAdmin、userAdminAnyDatabase 的 MongoDB 角色或具有同等特权的自定义角色。
使用 mongosh 对 MongoDB 服务器进行身份验证,并设置以下选项:
--host使用 MongoDB Server 的主机名--port使用 MongoDB 服务器的端口--username为用户的用户名--password为用户密码--authenticationMechanismto'PLAIN'--authenticationDatabaseto'$external'
例子
在此过程的前面,您在 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>
Windows MongoDB 部署必须使用mongo.exe,而不是 mongosh。
根据已配置 Active Directory 用户,用户可成功通过身份验证并获得相应权限。
注意
如果希望以现有的非 $external 用户身份进行身份验证,请将 --authenticationMechanism 设置为 SCRAM 身份验证机制(例如,视情况设为 SCRAM-SHA-1 或 SCRAM-SHA-256)。这要求 MongoDB 服务器的 setParameter authenticationMechanisms 包括 SCRAM-SHA-1 和/或 SCRAM-SHA-256。
创建用于映射返回的 AD 群组的角色。
对于AD服务器上要用于MongoDB授权的每个群组,必须在MongoDB服务器的admin数据库上创建一个匹配的角色。
例子
以下操作创建以AD群组DN 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.COM 或 alice@ENGINEERING.EXAMPLE.COM 的用户授予 PrimaryApplication 数据库上的 readWrite 角色。
注意
要管理 admin 数据库上的角色,您必须以拥有以下权限的用户身份进行身份验证:admin 上的 userAdmin,userAdminAnyDatabase,或具有同等权限的自定义角色。
将现有用户从 $external 转换到 ActiveDirectory服务器
如果使用在$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_analytics 和 PrimaryApplication 数据库上执行 read 操作。
如果要继续允许非$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 模式、目录结构和配置。 您的部署可能还需要其他配置文件选项。
有关配置角色和权限的更多信息,请参阅: