使用 Kerberos 身份验证和 Active Directory 授权配置 MongoDB

在本页面

• Prerequisites

• Considerations

• Procedure

3.4 版中的新功能：MongoDB Enterprise支持在 LDAP 服务器上查询经过身份验证的用户所属的 LDAP 组。 MongoDB 将每个返回的组的 LDAP 专有名称(DN)Map 到admin数据库上的roles。 MongoDB 根据 Map 的角色及其关联的特权来授权用户。有关更多信息，请参见LDAP Authorization。

MongoDB Enterprise 支持使用Kerberos service进行身份验证。 Kerberos 是用于大型 Client 端/服务器系统的行业标准身份验证协议。

本教程介绍如何配置 MongoDB 以通过 Kerberos 服务器执行身份验证，并通过平台库通过 Active Directory(AD)服务器进行授权。

Prerequisites

有关 AD 的完整描述不在本教程的讨论范围之内。本教程假定您具有 AD 的先验知识。

MongoDB 支持使用 SASL 机制在 MongoDB 服务器和 AD 之间进行绑定。对 SASL，SASL 机制或给定 SASL 机制的特定 AD 配置要求的完整描述不在本教程的范围内。本教程假定您具有 SASL 及其相关主题的先验知识。

设置和配置 Kerberos 部署超出了本文档的范围。本教程假定您为 MongoDB 部署中的每个mongod和mongos实例配置了一个Kerberos 服务主体，并且为每个mongod和mongos实例具有了一个有效的keytab file。

对于副本集和分片群集，请确保您的配置使用完全合格的域名(FQDN)，而不是 IP 地址或不合格的主机名。您必须使用 FQDN for GSSAPI 才能正确解析 Kerberos 领域并允许您进行连接。

要验证 MongoDB Enterprise 二进制文件，请将--version命令行选项传递给mongod或mongos：

mongod --version

在此命令的输出中，查找字符串modules: subscription或modules: enterprise以确认您的系统具有 MongoDB Enterprise。

Considerations

本教程介绍了如何配置 MongoDB 以进行 Kerberos 身份验证和 AD 授权。

要在您自己的 MongoDB 服务器上执行此过程，必须相对于您自己的特定基础结构(尤其是 Kerberos 配置，构造 AD 查询或 Management 用户)修改给定的过程。

传输层安全性

默认情况下，MongoDB 在绑定到 AD 服务器时会创建 TLS/SSL 连接。这要求将 MongoDB 服务器的主机配置为可以访问 AD 服务器的证书颁发机构(CA)证书。

本教程提供有关所需主机配置的说明。

本教程假定您有权访问 AD 服务器的 CA 证书，并且可以在 MongoDB 服务器上创建证书的副本。

Active Directory 架构示例

本教程使用以下示例 AD 对象作为提供的查询，配置和输出的基础。每个对象仅显示可能属性的子集。

User Objects

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

Group Objects

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有关的查询。

Replica Sets

MongoDB LDAP 授权要求副本集中的每个 mongod至少在 MongoDB 3.4.0 或更高版本上。

Sharded Clusters

MongoDB LDAP 授权要求分片群集中的每个 mongod和mongos至少在 MongoDB 3.4.0 或更高版本上。

Procedure

为运行 MongoDB 的服务器配置 TLS/SSL。

要通过 TLS/SSL 连接到 AD(AD)服务器，mongod或mongos要求访问 AD 服务器的证书颁发机构(CA)证书。

在 Linux 上，通过ldap.conf文件中的TLS_CACERT或TLS_CACERTDIR选项指定 AD 服务器的 CA 证书。

平台的程序包 Management 器在安装 MongoDB Enterprise 的libldap依赖项时会创建ldap.conf文件。有关配置文件或引用的选项的完整文档，请参阅ldap.conf。

在 Microsoft Windows 上，使用平台的凭据 Management 工具加载 AD 服务器的证书颁发机构(CA)证书。确切的凭据 Management 工具取决于 Windows 版本。要使用该工具，请参阅您的 Windows 版本的文档。

如果mongod或mongos无法访问 AD CA 文件，则它们将无法创建到 Active Directory 服务器的 TLS/SSL 连接。

(可选)将security.ldap.transportSecurity设置为none以禁用 TLS/SSL。

(仅 Windows)将服务主体名称分配给 MongoDB Windows 服务。

对于 Windowsos 上运行的 MongoDB 服务器，必须使用setspn.exe将服务主体名称(SPN)分配给运行 MongoDB 服务的帐户。

setspn.exe -S <service>/<fully qualified domain name> <service account name>

setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com

(仅 Linux)为 MongoDB 服务器创建密钥表文件。

对于在 Linux 平台上运行的 MongoDB 服务器，您必须确保该服务器具有特定于该服务器上运行的 MongoDB 实例的keytab file的副本。

您必须授予运行 MongoDB 服务的 Linux 用户对 keytab 文件的读取权限。记下 keytab 文件位置的完整路径。

连接到 MongoDB 服务器。

使用--host和--port选项使用mongo shell 连接到 MongoDB 服务器。

mongo --host <hostname> --port <port>

如果您的 MongoDB 服务器当前正在执行身份验证，则您必须以具有角色 Management 特权(例如userAdmin或userAdminAnyDatabase提供的角色)的用户身份向admin数据库进行身份验证。为 MongoDB 服务器的已配置身份验证机制添加适当的--authenticationMechanism。

mongo --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"

创建用户 Management 角色。

要使用 ADManagementMongoDB 用户，您需要在admin数据库上至少创建一个可以创建和 Management 角色的角色，例如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" ]
   }
)

您也可以为用户应具有用户 Management 特权的每个数据库授予userAdmin角色。这些角色为角色创建和 Management 提供了必要的特权。

创建一个 MongoDB 配置文件。

MongoDB configuration file是 extensions 为.conf的纯文本 YAML 文件。

• 如果要升级现有的 MongoDB 部署，请复制当前的配置文件并从该副本进行操作。

• (仅限 Linux)如果这是一个新部署并且您使用平台的程序包 Management 器来安装 MongoDB Enterprise，则安装中将包含/etc/mongod.conf默认配置文件。使用该默认配置文件，或制作该文件的副本以进行工作。

• 如果不存在这样的文件，请创建一个 extensions 为.conf的空文件，并从该新配置文件开始工作。

配置 MongoDB 以连接到 Active Directory`。

在 MongoDB 配置文件中，将security.ldap.servers设置为 AD 服务器的主机和端口。如果您的 AD 基础结构包括多个 AD 服务器以进行复制，请将服务器的主机和端口指定为security.ldap.servers，以逗号分隔。

security:
ldap:
servers: "activedirectory.example.net"

MongoDB 必须绑定到 AD 服务器才能执行查询。默认情况下，MongoDB 使用简单的身份验证机制将自身绑定到 AD 服务器。

或者，您可以在配置文件中配置以下设置以使用SASL绑定到 AD 服务器：

• 将security.ldap.bind.method设置为sasl

• security.ldap.bind.saslMechanisms，指定 AD 服务器支持的字符串，以逗号分隔。

本教程使用默认的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。设计查询模板以检索经过身份验证的用户的组。

security:
ldap:
authz:
queryTemplate:
"DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"

MongoDB 将每个返回的组 DNMap 到admin数据库上的角色。对于每个 Map 的组 DN，如果admin数据库上存在一个名称与 DN 完全匹配的现有角色，则 MongoDB 会向用户授予角色和分配给该角色的特权。

匹配规则LDAP_MATCHING_RULE_IN_CHAIN要求提供身份验证用户的完整 DN。由于 Kerberos 需要使用用户的userPrincipalName进行身份验证，因此您必须使用security.ldap.userToDNMapping将传入的用户名转换为 DN。下一步提供了有关转换传入的用户名以支持queryTemplate的指导。

转换传入的用户名以通过 Active Directory 进行身份验证。

在 MongoDB 配置文件中，设置userToDNMapping将身份验证用户提供的用户名转换为 AD DN 以支持queryTemplate。

security:
ldap:
userToDNMapping:
'[
{
match : "(.+)",
ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
}
]'

您必须修改给定的 samples 配置以匹配您的部署。例如，ldapQuery基本 DN 必须与包含您的用户实体的基本 DN 相匹配。为了支持您的 AD 部署，可能需要进行其他修改。

DC=example,DC=com??sub?(userPrincipalName=alice@ENGINEERING.EXAMPLE.COM)

配置查询凭据。

MongoDB 需要凭据才能在 AD 服务器上执行查询。

在配置文件中配置以下设置：

• security.ldap.bind.queryUser，指定mongod或mongos绑定的 Kerberos 用户，就像在 AD 服务器上执行查询一样。

• security.ldap.bind.queryPassword，为指定的queryUser指定密码。

security:
  ldap:
    bind:
      queryUser: "mongodbadmin@dba.example.com"
      queryPassword: "secret123"

在 Windows MongoDB 服务器上，可以将security.ldap.bind.useOSDefaults设置为true以使用 OS 用户的凭据，而不是queryUser和queryPassword。

queryUser必须具有代表 MongoDB 执行所有 LDAP 查询的权限。

可选：添加其他配置设置。

包括配置所需的其他选项。例如，如果您希望远程 Client 端连接到您的部署，或者您的部署成员在不同的主机上运行，请指定net.bindIp设置。有关更多信息，请参见Localhost 绑定兼容性更改。

使用 Kerberos 身份验证和 Active Directory 授权启动 MongoDB 服务器。

使用--config选项启动 MongoDB 服务器，并指定在此过程中创建的配置文件的路径。如果 MongoDB 服务器当前正在运行，请进行适当的准备以停止服务器。

Linux MongoDB Servers

在 Linux 上，您必须指定KRB5_KTNAME环境变量，并指定 MongoDB 服务器的 keytab 文件的路径。

env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>

Microsoft Windows MongoDB Servers

在 Windows 上，您必须按照过程中前面的配置将 MongoDB 服务器作为服务主体帐户启动：

mongod.exe --config <path-to-config-file>

连接到 MongoDB 服务器。

连接到 MongoDB 服务器，以其直接或传递组成员身份与userAdmin，userAdminAnyDatabase或具有等效特权的自定义角色对应于admin数据库上的 MongoDB 角色的用户身份进行身份验证。

使用mongo shell 对 MongoDB 服务器进行身份验证，设置以下选项：

• --host，带有 MongoDB 服务器的主机名

• --port与 MongoDB 服务器的端口

• --username到用户的userPrincipalName

• --password用户密码

• --authenticationMechanism至"GSSAPI"

• --authenticationDatabase至"$external"

mongo --username sam@DBA.EXAMPLE.COM --password 'secret123' --authenticationMechanisms="GSSAPI" --authenticationDatabase "$external" --host <hostname> --port <port>

Windows MongoDB 部署必须使用mongo.exe而不是mongo。

给定已配置的Active Directory 用户，用户将成功进行身份验证并接收适当的权限。

创建用于 Map 返回的 AD 组的角色。

对于要用于 MongoDB 授权的 AD 服务器上的每个组，必须在 MongoDB 服务器的admin数据库上创建匹配角色。

db.getSiblingDB("admin").createRole(
{
role: "CN=PrimaryApplication,CN=Users,DC=example,DC=com",
privileges: [],
roles: [
{ role: "readWrite", db: "PrimaryApplication" }
]
}
)

可选：将现有用户从$ external 过渡到 Active Directory 服务器。

如果使用$external数据库上配置的users升级现有安装，则必须为每个用户满足以下要求，以确保在为 MongoDB 配置 Kerberos 身份验证和 AD 授权后进行访问：

• 用户在 AD 服务器上具有相应的用户对象。

• 用户在 AD 服务器上的适当组中具有成员身份。

• MongoDB 包含admin数据库中以用户的 AD 组命名的角色，以便授权用户保留其特权。

{
user : "joe@ANALYTICS.EXAMPLE.COM",
roles: [
{ role : "read", db : "web_analytics" },
{ role : "read", db : "PrimaryApplication" }
]
}

db.getSiblingDB("admin").createRole(
{
role: "CN=marketing,CN=Users,DC=example,DC=com",
privileges: [],
roles: [
{ role: "read", db: "web_analytics" }
{ role: "read", db: "PrimaryApplication" }
]
}
)

如果要 continue 允许非$external数据库上的用户访问 MongoDB，则必须在setParameter authenticationMechanisms配置选项中包括SCRAM-SHA-1。

setParameter:
  authenticationMechanisms: "GSSAPI,SCRAM-SHA-1"

或者，按照上述步骤将非$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"

有关配置角色和特权的更多信息，请参见：

• 基于角色的访问控制

• privilege actions

• 集合级访问控制