使用 Kerberos 身份验证和 Active Directory 授权配置自管理 MongoDB
3.4版本新增: MongoDB Enterprise支持在LDAP服务器中查询经过身份验证的用户所属的LDAP群组。 MongoDB将每个返回群组的LDAP标识名 (DN) 映射到 admin
数据库上的角色。 MongoDB根据映射的角色及其关联的权限对用户进行授权。 有关更多信息,请参阅LDAP授权。
MongoDB Enterprise 支持使用 Kerberos 服务进行身份验证。Kerberos 是一种面向大型客户端/服务器系统的行业标准身份验证协议。
本教程介绍如何配置 MongoDB,以借助平台库通过 Kerberos 服务器执行身份验证,并通过 Active Directory (AD) 服务器执行授权。
先决条件
重要
在继续之前,请充分熟悉以下主题:
对 AD的完整描述超出了本教程的范围。 本教程假定您已了解AD 。
MongoDB 支持使用 SASL 机制在 MongoDB Server 和AD之间进行绑定。 SASL、SASL 机制或给定 SASL 机制的特定AD配置要求的完整描述超出了本教程的范围。 本教程假定您已了解 SASL 及其相关主题。
设置和配置 Kerberos 部署超出了本文档的范围。本教程假设您已为 MongoDB 部署中的每个 mongod
和 mongos
实例配置了 Kerberos 服务主体,并且对于每个 mongod
和 mongos
实例,您都有一个有效的密钥表文件。
对于副本集和分片集群,请确保配置使用完全限定的域名 (FQDN),而不是 IP 地址或未限定的主机名。您必须使用 GSSAPI 的 FQDN 才能正确解析 Kerberos Realm 并允许连接。
要验证您是否使用 MongoDB Enterprise,请将 --version
命令行选项传递给 mongod
或 mongos
:
mongod --version
在该命令的输出中,请查找字符串 modules:
subscription
或 modules: enterprise
,以确认您使用的是 MongoDB Enterprise 二进制文件。
Considerations
本教程介绍如何为 Kerberos 身份验证和AD授权配置 MongoDB。
要在自己的 MongoDB 服务器上执行此过程,您必须根据自己的特定基础架构(尤其是 Kerberos 配置、构建AD查询或管理用户)修改给定过程。
传输层安全
默认情况下,MongoDB 在绑定到AD服务器时会创建 TLS/SSL 连接。 这需要配置 MongoDB Server 的主机,使其有权访问 AD 服务器的证书颁发机构 (CA) 证书。
本教程提供所需主机配置的说明。
本教程假设您可以访问 AD 服务器的 CA 证书,并可以在 MongoDB 服务器上创建证书副本。
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服务器之间传输明文信息,包括用户档案。
(仅限 Windows)为 MongoDB Windows 服务分配服务主体名称。
对于在 Windows 操作系统上运行的 MongoDB 服务器,必须使用 setspn.exe 将服务主体名称 (SPN) 分配给运行 MongoDB 服务的帐户。
setspn.exe -S <service>/<fully qualified domain name> <service account name>
例子
例如,如果 mongod
作为名为 mongodb
的服务在 mongodbserver.example.com
上运行,服务帐户名称为 mongodb_dev@example.com
,则分配 SPN 的命令如下所示:
setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com
注意
Windows MongoDB Server 2003 不支持 setspn.exe -S
。 有关setspn.exe
的完整文档,请参阅 setspn.exe 。
(仅限 Linux)为 MongoDB 服务器创建密钥表文件。
对于 Linux 平台上运行的 MongoDB 服务器,必须确保服务器具有特定于该服务器上运行的 MongoDB 实例的密钥表文件的副本。
您必须授予运行 MongoDB 服务的 Linux 用户对密钥表文件的读取权限。记下密钥表文件位置的完整路径。
连接到 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>"
创建用户管理角色。
要托管ADMongoDB 用户,您需要在可以创建和托管角色的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 角色、 AD 群组或群组成员身份时。
创建 MongoDB 配置文件。
MongoDB 配置文件是具有 .conf
文件扩展名的纯文本 YAML 文件。
如果您正在升级现有的 MongoDB 部署,请复制当前配置文件并从该副本开始工作。
(仅限 Linux)如果这是新部署,并且您使用了平台的包管理器来安装 MongoDB Enterprise,则该安装将包含
/etc/mongod.conf
默认配置文件。使用该默认配置文件,或复制该文件以供使用。如果不存在此类文件,请创建一个扩展名为
.conf
的空文件,然后从该新配置文件进行操作。
配置 MongoDB 以连接到 Active Directory。
在 MongoDB 配置文件中,将security.ldap.servers
设置为AD Server 的主机和端口。 如果您的AD基础架构包含多个用于复制的AD服务器,请将服务器的主机和端口指定为security.ldap.servers
的逗号分隔列表。
例子
要连接到位于activedirectory.example.net
的AD服务器,请在配置文件中包含以下内容:
security: ldap: servers: "activedirectory.example.net"
MongoDB 必须绑定到AD服务器才能执行查询。 默认情况下,MongoDB 使用简单身份验证机制将自身绑定到AD服务器。
或者,您可以在配置文件中配置以下设置,以使用SASL
绑定到AD服务器:
将
security.ldap.bind.method
设置为sasl
。security.ldap.bind.saslMechanisms
,指定AD服务器支持的一串以逗号分隔的 SASL 机制。
本教程使用默认的 simple
LDAP 身份验证机制。
配置 MongoDB 进行 Kerberos 身份验证。
在 MongoDB 配置文件中,将 security.authorization
设置为enabled
,并将 setParameter
authenticationMechanisms
设置为 GSSAPI
要启用通过 Kerberos 进行身份验证,请在配置文件中包含以下内容:
security: authorization: "enabled" setParameter: authenticationMechanisms: "GSSAPI"
为授权配置 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.1941
LDAP_MATCHING_RULE_IN_CHAIN 的 AD 特定匹配规则 OID 。此匹配规则是 LDAPAtlas Search筛选器的特定于 AD 的扩展。
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 服务器对直接或间接将用户列为成员的任何群组执行递归群组查找。 AD Server 根据 Active Directory 群组 返回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
要求提供身份验证用户的完整标识名 。由于 Kerberos 要求使用用户的userPrincipalName
进行身份验证,因此您必须使用 将传入的用户名转换为 DN security.ldap.userToDNMapping
。下一步将提供有关转换传入用户名以支持queryTemplate
的指导。
转换传入的用户名,以便通过 Active Directory 进行身份验证。
在 MongoDB 配置文件中,设置userToDNMapping
以将身份验证用户提供的用户名转换为AD DN,以支持queryTemplate
。
例子
以下 userToDNMapping
配置使用 match
正则表达式过滤器来捕获所提供的用户名。在执行查询之前,MongoDB 将捕获的用户名插入到 ldapQuery
查询模板中。
security: ldap: userToDNMapping: '[ { match : "(.+)", ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})" } ]'
您必须修改给定的示例配置以匹配您的部署。 例如, 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
在AD服务器上执行查询时绑定的 Kerberos 用户。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 查询的权限。
可选:添加其他配置设置。
根据配置要求包括其他选项。例如,如果您希望远程客户端连接到部署,或者部署节点运行在不同的主机上,请指定 net.bindIp
设置。
使用 Kerberos 身份验证和 Active Directory 授权启动 MongoDB 服务器。
使用 --config
选项启动 MongoDB 服务器,并指定在此过程中创建的配置文件的路径。如果 MongoDB 服务器当前正在运行,请做好适当的准备以停止服务器。
Linux MongoDB Servers
在 Linux 上,您必须指定 KRB5_KTNAME
环境变量,从而指定用于 MongoDB 服务器的密钥表文件路径。
env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>
Microsoft Windows MongoDB Servers
在Windows上,您必须按照此过程前面的配置以服务主体帐户身份启动 MongoDB Server:
mongod.exe --config <path-to-config-file>
连接到 MongoDB Server。
连接到 MongoDB 服务器,以特定用户身份进行身份验证,该用户的直接或可传递群组成员身份对应于 admin
数据库上具有 userAdmin
、userAdminAnyDatabase
的 MongoDB 角色或具有同等特权的自定义角色。
使用 mongosh
对 MongoDB 服务器进行身份验证,并设置以下选项:
--host
使用 MongoDB Server 的主机名--port
使用 MongoDB 服务器的端口--username
到用户的userPrincipalName
--password
,提供用户的密码(或省略以让mongosh
提示输入密码)--authenticationMechanism
to"GSSAPI"
--authenticationDatabase
to"$external"
例子
在此过程的前面,您在admin
数据库上配置了dn:CN=dba,CN=Users,DC=example,DC=com
角色以及所需的权限。 该角色对应于一个AD群组。 根据配置的AD 用户,您可以以用户sam@dba.example.com
身份进行身份验证并获得所需的权限。
mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanisms="GSSAPI" --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群组 标识名 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
转换到 Active Directory服务器。
如果使用在$external
数据库上配置的用户升级现有安装,则必须满足每个用户的以下要求,以确保在为 Kerberos 身份验证和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
操作。
重要
为相应的AD群组配置角色时,请记住,具有该群组成员身份的所有用户都可以接收分配的角色和权限。 考虑应用 最小特权原则 配置 MongoDB 角色、 AD 群组或群组成员身份时。
如果想要继续允许非 $external
数据库上的用户访问 MongoDB,则必须将 SCRAM 身份验证机制(例如 SCRAM-SHA-1
和/或 SCRAM-SHA-256
)纳入 setParameter
authenticationMechanisms
配置选项中。
setParameter: authenticationMechanisms: "GSSAPI,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: "GSSAPI"
重要
The given sample configuration requires modification to match your AD schema, directory structure, and configuration. 您的部署可能还需要其他配置文件选项。
有关配置角色和权限的更多信息,请参阅:
测试与验证
完成配置步骤后,可以使用 mongokerberos
工具验证配置。
mongokerberos
提供了一种便捷的方法,以验证您的平台的 Kerberos 配置是否与 MongoDB 一起使用,并测试 MongoDB 客户端的 Kerberos 身份验证是否按预期运行。有关更多信息,请参阅 mongokerberos
文档。
mongokerberos
仅在 MongoDB Enterprise 中可用。