从版本3.4开始,MongoDB Enterprise通过平台LDAP库提供支持,以将身份验证和授权请求代理到指定的轻型目录访问协议(LDAP)服务,例如Active Directory(AD)。
本教程介绍了如何配置MongoDB以通过平台库通过Active Directory(AD)服务器执行身份验证和授权。
注意
对于链接到的MongoDB 4.2(和4.0.9)企业二进制文件
libldap
(例如在RHEL上运行时),对的访问
libldap
是同步的,这会导致性能/延迟成本。
对于链接到的MongoDB 4.2(和4.0.9)企业二进制文件,与
libldap_r
早期MongoDB版本相比,行为没有变化。
有关AD的完整描述不在本教程的讨论范围之内。本教程假定您具有AD的先验知识。
MongoDB支持使用SASL机制在MongoDB服务器和AD之间进行绑定。对SASL,SASL机制或给定SASL机制的特定AD配置要求的完整描述不在本教程的范围内。本教程假定您具有SASL及其相关主题的先验知识。
本教程介绍了如何配置MongoDB以进行AD 身份验证和授权。
要在您自己的MongoDB服务器上执行此过程,必须相对于您自己的特定基础结构修改给定的过程,尤其是Active Directory配置,构建AD 查询或管理用户。
默认情况下,MongoDB在绑定到AD服务器时会创建TLS / SSL连接。这要求将MongoDB服务器的主机配置为有权访问AD服务器的证书颁发机构(CA)证书。
本教程提供有关所需主机配置的说明。
本教程假定您有权访问AD服务器的CA证书,并且可以在MongoDB服务器上创建证书的副本。
在版本3.6.3中更改:要与$external
身份验证用户(即Kerberos,LDAP,x.509用户)一起使用会话,用户名不能大于10k字节。
本教程使用用户名和密码在AD服务器上执行查询
。提供的凭据必须在AD服务器上具有足够的特权,才能支持与security.ldap.userToDNMapping
或
相关的查询
security.ldap.authz.queryTemplate
。
要通过TLS / SSL 连接到AD(AD)服务器,请
访问mongod
或mongos
要求访问AD服务器的证书颁发机构(CA)证书。
在Linux上,通过文件中的或选项指定AD服务器的CA证书。TLS_CACERT
TLS_CACERTDIR
ldap.conf
平台的程序包管理器ldap.conf
在安装MongoDB Enterprise的libldap
依赖项时创建文件。有关配置文件或引用的选项的完整文档,请参阅
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服务器之间传输纯文本信息,包括用户凭据。
mongo
使用--host
和--port
选项,使用Shell
连接到MongoDB服务器。
如果您的MongoDB服务器当前正在执行身份验证,则您必须以admin
具有角色管理特权的用户身份向数据库进行身份验证,例如userAdmin
或
提供的特权userAdminAnyDatabase
。包括适用
--authenticationMechanism
于MongoDB服务器的已配置身份验证机制的内容。
注意
对于Windows MongoDB部署,应替换mongo
为
mongo.exe
要使用AD管理MongoDB用户,您需要在admin
数据库上至少创建一个可以创建和管理角色的角色,例如userAdmin
或
提供的角色userAdminAnyDatabase
。
角色名称必须与AD组的专有名称完全匹配。该组必须至少有一个AD用户作为成员。
给定可用的Active Directory组,执行以下操作:
CN=dba,CN=Users,DC=example,DC=com
,然后userAdminAnyDatabase
在admin
数据库上为其分配角色。您也可以userAdmin
为该用户应具有用户管理权限的每个数据库授予该角色。这些角色为角色创建和管理提供了必要的特权。
重要
在配置MongoDB角色,AD组或组成员身份时,请考虑应用最小特权原则。
在MongoDB配置文件中,设置security.ldap.servers
为AD服务器的主机和端口。如果您的
AD基础结构为了复制目的而包括多个AD服务器,则将服务器的主机和端口指定为以逗号分隔的列表
security.ldap.servers
。
您还必须通过将设置security.authorization
为enabled和来启用LDAP身份验证
setParameter
authenticationMechanisms
PLAIN
例
要连接位于的AD服务器
activedirectory.example.net
,请在配置文件中包括以下内容:
MongoDB必须绑定到AD服务器才能执行查询。默认情况下,MongoDB使用简单的身份验证机制将自身绑定到AD服务器。
或者,您可以使用以下命令在配置文件中配置以下设置以绑定到AD服务器SASL
:
security.ldap.bind.method
于sasl
security.ldap.bind.saslMechanisms
,指定AD服务器支持的一串以逗号分隔的SASL机制。本教程使用默认的simple
LDAP认证机制。
在MongoDB配置文件中,设置
security.ldap.authz.queryTemplate
为RFC4516格式的LDAP查询URL模板。
在模板中,您可以使用以下任一方法:
{USER}
占位符,以将经过身份验证的用户名替换为LDAP查询URL。{PROVIDED_USER}
占位符,以将提供的用户名(即在身份验证或LDAP转换之前)替换为LDAP查询。(从版本4.2开始可用)注意
RFC4515,RFC4516或AD查询的完整描述超出了本教程的范围。在queryTemplate
本教程中提供只是一个例子,可能并不适用于您的特定AD部署。
例
以下查询模板{USER}
在递归组成员身份之后返回列出为成员的任何组。该LDAP查询假定组对象通过使用member
属性存储完整的用户专有名称(DN)来跟踪用户成员身份。查询包括AD特定匹配规则OID
1.2.840.113556.1.4.1941
为LDAP_MATCHING_RULE_IN_CHAIN。此匹配规则是LDAP搜索过滤器的AD特定扩展。
使用查询模板,MongoDB替换{USER}
为经过身份验证的用户名,以查询LDAP服务器。
例如,用户认证为
CN=sam,CN=Users,DC=dba,DC=example,DC=com
。MongoDB基于创建一个LDAP查询queryTemplate
,{USER}
用已认证/已转换的用户名替换令牌。Active Directory服务器对直接或通过传递方式将用户列为成员的任何组执行递归组查找。基于
Active Directory组,
AD服务器返回
CN=dba,CN=Users,DC=example,DC=com
和
CN=engineering,CN=Users,DC=example,DC=com
。
MongoDB将每个返回的组DN映射到admin
数据库上的一个角色。对于每个映射的组DN,如果admin
数据库中存在一个名称与DN完全匹配的现有角色,则MongoDB会向用户授予角色和分配给该角色的特权。
匹配规则LDAP_MATCHING_RULE_IN_CHAIN
要求提供身份验证用户的完整DN。如果用户使用不同的用户名格式,如他们的身份验证,您必须将传入的用户名进入DN的使用。user
principal name
security.ldap.userToDNMapping
如果您的用户使用不是完整LDAP DN的用户名进行身份验证,则可能需要转换用户名以支持LDAP身份验证或授权。MongoDB使用转换后的用户名进行身份验证和授权。
在MongoDB配置文件中,设置
userToDNMapping
为将身份验证用户提供的用户名转换为AD DN以支持queryTemplate
。
例
鉴于已配置queryTemplate
,用户必须使用其完整LDAP DN进行身份验证。如果用户改为使用进行身份验证userPrincipalName
,则必须应用转换将提供的用户名转换为完整的LDAP DN。
以下userToDNMapping
配置使用match
正则表达式过滤器来捕获提供的用户名。MongoDB ldapQuery
在执行查询之前将捕获的用户名插入查询模板。
Active Directory服务器返回与用户对象相关联的完整LDAP DN,并带有匹配项userPrincipalName
。然后,MongoDB可以使用此转换后的用户名进行身份验证和授权。
您必须修改给定的样本配置以匹配您的部署。例如,ldapQuery
基础DN必须基本符合DN包含用户的实体。为了支持您的AD部署,可能需要进行其他修改。
例
用户认证为alice@ENGINEERING.EXAMPLE.COM
。MongoDB首先应用中指定的任何转换
userToDNMapping
。根据提供的配置,MongoDB在match
阶段中捕获用户名并执行LDAP查询:
根据配置的Active Directory用户,AD服务器应返回
CN=alice,CN=Users,DC=engineering,DC=example,DC=com
。
然后,MongoDB执行在中配置的LDAP查询
queryTemplate
,将{USER}
令牌替换为转换后的用户名
CN=alice,CN=Users,DC=engineering,DC=example,DC=com
。
重要
如果您使用userToDNMapping
的
substitution
参数来转换组名,则替换的结果必须是RFC4514转义字符串。
MongoDB需要凭据才能在AD服务器上执行查询。
在配置文件中配置以下设置:
security.ldap.bind.queryUser
,指定Active Directory用户
mongod
或mongos
绑定,以在AD服务器上执行查询。security.ldap.bind.queryPassword
,为指定的指定密码queryUser
。在Windows MongoDB服务器上,可以设置
security.ldap.bind.useOSDefaults
为true
使用OS用户的凭据而不是queryUser
和queryPassword
。
在queryUser
必须有代表的MongoDB执行所有LDAP查询的权限。
添加部署所需的所有其他配置选项。例如,您可以指定所需的名称storage.dbPath
或更改默认net.port
号码。
开始在MongoDB中3.6,mongod
并mongos
绑定默认为localhost。如果部署的成员在不同的主机上运行,或者希望远程客户端连接到部署,则必须指定net.bindIp
设置。有关更多信息,请参见Localhost绑定兼容性更改。
使用--config
选项启动MongoDB服务器,指定在此过程中创建的配置文件的路径。如果MongoDB服务器当前正在运行,请进行适当的准备以停止服务器。
Windows MongoDB部署必须使用
mongod.exe
而不是mongod
。
连接到MongoDB服务器,认证作为其直接还是间接组成员对应一个MongoDB的角色上的用户admin
数据库userAdmin
,userAdminAnyDatabase
或具有同等权限的自定义角色。
使用mongo
外壳对MongoDB服务器进行身份验证,设置以下选项:
--host
使用MongoDB服务器的主机名--port
与MongoDB服务器的端口--username
用户的用户名--password
用户密码--authenticationMechanism
至 'PLAIN'
--authenticationDatabase
至 '$external'
例
在此过程之前,您dn:CN=dba,CN=Users,DC=example,DC=com
已admin
使用所需的权限在数据库上配置了
角色。该角色对应一个AD组。基于已配置的AD用户,您可以作为用户进行身份验证
sam@dba.example.com
并接收所需的权限。
Windows MongoDB部署必须使用
mongo.exe
而不是mongo
。
给定已配置的Active Directory用户,该用户将成功进行身份验证并接收适当的权限。
注意
如果您想以现有的非$external
用户身份进行身份验证,请设置
--authenticationMechanism
为SCRAM身份验证机制(例如SCRAM-SHA-1
或SCRAM-SHA-256
根据需要)。这要求MongoDB服务器的include 和/或。setParameter
authenticationMechanisms
SCRAM-SHA-1
SCRAM-SHA-256
对于要用于MongoDB授权的AD服务器上的每个组,必须在MongoDB服务器的admin
数据库上创建匹配角色。
例
以下操作将创建一个以AD组DN 命名的CN=PrimaryApplication,CN=Users,DC=example,DC=com
角色,并为该组分配适当的角色和特权:
由于配置的Active Directory组,MongoDB的授予用户认证为无论是sam@DBA.EXAMPLE.COM
或alice@ENGINEERING.EXAMPLE.COM
将
readWrite
在角色上的PrimaryApplication
数据库。
注意
为了管理上的角色admin
数据库,您必须验证为与用户userAdmin
上admin
,
userAdminAnyDatabase
或在具有同等权限的自定义角色。