Docs Menu
Docs Home
/ /
Kerberos
/ / / / /

Configurar MongoDB autogestionado con Kerberos y autorización de Active Directory

MongoDB Enterprise permite consultar un servidor LDAP para conocer los grupos LDAP a los que pertenece un usuario autenticado. MongoDB asigna los nombres distinguidos (DN) LDAP de cada grupo devuelto a roles en el admin Base de datos. MongoDB autoriza al usuario según los roles asignados y sus privilegios asociados. Consulte Autorización LDAP para obtener más información.

MongoDB Enterprise admite la autenticación utilizando un servicio Kerberos. Kerberos es un protocolo estándar de autenticación de la industria para grandes sistemas cliente/servidor.

Este tutorial describe cómo configurar MongoDB para realizar autenticación a través de un servidor Kerberos y autorización a través de un servidor Active Directory (AD) mediante las librerías de la plataforma.

Importante

Familiarícese completamente con los siguientes temas antes de continuar:

Una descripción completa de AD queda fuera del alcance de este tutorial. Se presupone un conocimiento previo de AD.

MongoDB admite el uso de mecanismos SASL para la vinculación entre el servidor MongoDB y AD. Una descripción completa de SASL, sus mecanismos o los requisitos específicos de configuración de AD para un mecanismo SASL determinado quedan fuera del alcance de este tutorial. Este tutorial presupone conocimientos previos de SASL y temas relacionados.

La configuración de una implementación de Kerberos queda fuera del alcance de este documento. Este tutorial asume que ha configurado una entidad de servicio Kerberos para cada mongod mongos instancia y en su implementación de MongoDB, y que dispone de un archivo keytab válido para cada instancia mongod mongos y.

Para conjuntos de réplicas y clústeres fragmentados, asegúrese de que su configuración utilice nombres de dominio completos (FQDN) en lugar de direcciones IP o nombres de host sin calificar. Debe usar el FQDN para que GSSAPI resuelva correctamente los dominios Kerberos y le permita conectarse.

Para verificar que está utilizando MongoDB Enterprise, pase la --version opción de línea de comando a mongod mongoso:

mongod --version

En la salida de este comando, busque la cadena modules: subscription o modules: enterprise para confirmar que está utilizando los binarios de MongoDB Enterprise.

Este tutorial explica cómo configurar MongoDB para la autenticación Kerberos y la autorización de AD.

Para realizar este procedimiento en su propio servidor MongoDB, debe modificar los procedimientos indicados con respecto a su infraestructura específica, especialmente las configuraciones de Kerberos, la construcción de consultas de AD o la administración de usuarios.

De forma predeterminada, MongoDB crea una conexión TLS/SSL al vincularse al servidor de AD. Esto requiere configurar el host del servidor MongoDB para que tenga acceso a los certificados de la autoridad de certificación (CA) del servidor de AD.

Este tutorial proporciona instrucciones para las configuraciones del host requeridas.

Este tutorial asume que tiene acceso a los certificados CA del servidor AD y puede crear una copia de los certificados en el servidor MongoDB.

Este tutorial utiliza los siguientes objetos de AD de ejemplo como base para las consultas, configuraciones y resultados proporcionados. Cada objeto muestra solo un subconjunto de los atributos posibles.

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

Este tutorial utiliza un nombre de usuario y una contraseña para realizar consultas en el servidor AD. Las credenciales proporcionadas deben tener privilegios suficientes en el servidor AD para realizar consultas relacionadas con security.ldap.userToDNMapping security.ldap.authz.queryTemplateo.

La autorización LDAP de MongoDB requiere que cada mongod en el set de réplicas esté al menos en MongoDB 3.4.0 o posterior.

La autorización LDAP de MongoDB requiere que cada mongod y en el clúster fragmentado estén al menos en mongos MongoDB 3.4.0 o posterior.

1

Para conectarse al servidor AD (AD) a través de TLS/SSL, mongod o requieren mongos acceso al certificado de autoridad de certificación (CA) del servidor AD.

En Linux, especifique los certificados CA del servidor AD mediante TLS_CACERT TLS_CACERTDIR la ldap.conf opción o en el archivo.

El gestor de paquetes de su plataforma crea el ldap.conf archivo al instalar la dependencia de MongoDB libldap Enterprise. Para obtener la documentación completa sobre el archivo de configuración o las opciones referenciadas, consulte ldap.conf.

En Microsoft Windows, cargue los certificados de la autoridad de certificación (CA) del servidor AD con la herramienta de administración de credenciales de la plataforma. La herramienta de administración de credenciales exacta depende de la versión de Windows. Para usarla, consulte la documentación correspondiente a su versión de Windows.

Si mongod o mongos no pueden acceder a los archivos CA de AD, no podrán crear conexiones TLS/SSL al servidor de Active Directory.

Opcionalmente, configure security.ldap.transportSecurity en none para deshabilitar TLS/SSL.

Advertencia

La configuración transportSecurity de none a transmite información de texto sin formato, incluidas las credenciales del usuario, entre MongoDB y el servidor AD.

2

Para los servidores MongoDB que se ejecutan en el sistema operativo Windows, debe usar setspn.exe para asignar el nombre principal del servicio (SPN) a la cuenta que ejecuta el servicio MongoDB.

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

Ejemplo

Por ejemplo, si un se ejecuta como un servicio mongod llamado mongodb en mongodbserver.example.com con el nombre de cuenta de mongodb_dev@example.com servicio, el comando para asignar el SPN se vería así:

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

Nota

Windows Server 2003 no es compatible setspn.exe -S con. Para obtener la documentación completa setspn.exe sobre, consulte setspn.exe.

3

Para los servidores MongoDB que se ejecutan en la plataforma Linux, debe asegurarse de que el servidor tenga una copia del archivo keytab específico de la instancia MongoDB que se ejecuta en ese servidor.

Debe otorgar permisos de lectura al usuario de Linux que ejecuta el servicio MongoDB en el archivo keytab. Anote la ruta completa del archivo keytab.

4

Conéctese al servidor MongoDB usando mongosh usando las opciones --host --port y.

mongosh --host <hostname> --port <port>

Si su servidor MongoDB actualmente aplica autenticación, debe autenticarse en la admin base de datos como un usuario con privilegios de administración de roles, como los proporcionados por o. Incluya userAdmin el correspondiente userAdminAnyDatabase --authenticationMechanism al mecanismo de autenticación configurado en el servidor MongoDB.

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

Nota

Para las implementaciones de Windows MongoDB, debe reemplazar mongosh por mongo.exe

5

Para administrar usuarios de MongoDB mediante AD, debe crear al menos un rol en la admin base de datos que pueda crear y administrar roles, como los proporcionados por userAdmin o.userAdminAnyDatabase

El nombre del rol debe coincidir exactamente con el nombre distintivo de un grupo de AD. El grupo debe tener al menos un usuario de AD como miembro.

Dados los grupos de Active Directory disponibles, se realiza la siguiente operación:

  • Crea un rol denominado para el grupo de AD CN=dba,CN=Users,DC=example,DC=com y

  • Le asigna el rol en userAdminAnyDatabase la admin base de datos.

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

También puede otorgar el userAdmin rol para cada base de datos en la que el usuario deba tener privilegios administrativos. Estos roles proporcionan los privilegios necesarios para la creación y gestión de roles.

Importante

Considere aplicar el principio de mínimo privilegio al configurar roles de MongoDB, gruposde AD o membresía de grupos.

6

Un archivo de configuración de MongoDB es un archivo YAML de texto simple con la .conf extensión de archivo.

  • Si va a actualizar una implementación existente de MongoDB, copie el archivo de configuración actual y trabaje a partir de esa copia.

  • (Solo Linux) Si se trata de una nueva implementación y utilizó el gestor de paquetes de su plataforma para instalar MongoDB Enterprise, la instalación incluye el /etc/mongod.conf archivo de configuración predeterminado. Use dicho archivo o haga una copia para trabajar con él.

  • Si no existe dicho archivo, cree un archivo vacío con la extensión .conf y trabaje desde ese nuevo archivo de configuración.

7

En el archivo de configuración de MongoDB, asigne security.ldap.servers al host y puerto del servidor de AD. Si su infraestructura de AD incluye varios servidores de AD para la replicación, especifique el host y puerto security.ldap.servers de los servidores como una lista delimitada por comas hasta.

Ejemplo

Para conectarse a un servidor AD ubicado activedirectory.example.net en, incluya lo siguiente en el archivo de configuración:

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

MongoDB debe vincularse al servidor AD para realizar consultas. De forma predeterminada, MongoDB utiliza el mecanismo de autenticación simple para vincularse al servidor AD.

Como alternativa, puede configurar los siguientes ajustes en el archivo de configuración para vincularse al servidor AD SASL mediante:

Este tutorial utiliza el mecanismo de autenticación LDAP predeterminado simple.

8

En el archivo de configuración de MongoDB, establezca security.authorization en enabled y setParameter authenticationMechanisms en GSSAPI

Para habilitar la autenticación a través de Kerberos, incluye lo siguiente en el archivo de configuración:

security:
authorization: "enabled"
setParameter:
authenticationMechanisms: "GSSAPI"
9

En el archivo de configuración de MongoDB, establezca en security.ldap.authz.queryTemplate una plantilla de URL de consulta LDAP con formato 4516 RFC.

En la plantilla, puedes usar:

  • {USER} marcador de posición para sustituir el nombre de usuario autenticado en la URL de consulta LDAP.

  • {PROVIDED_USER} marcador de posición para sustituir el nombre de usuario suministrado, es decir, antes de la autenticación o la transformación LDAP, en la query LDAP.

Diseñá la plantilla de query para recuperar los grupos del usuario.

Nota

Este tutorial no aborda una descripción completa 45154516 de las queryTemplate consultas RFC, RFC ni de AD. El que se proporciona en este tutorial es solo un ejemplo y podría no ser aplicable a su implementación específica de AD.

Ejemplo

La siguiente plantilla de consulta devuelve cualquier grupo que incluya {USER} a como miembro, siguiendo las membresías recursivas de grupo. Esta consulta LDAP asume que los objetos de grupo rastrean la membresía del usuario almacenando su nombre distinguido (DN) completo mediante el member atributo. La consulta incluye el OID de la regla de coincidencia específica de AD 1.2.840.113556.1.4.1941 para LDAP_MATCHING_RULE_IN_CHAIN. Esta regla de coincidencia es una extensión específica de AD para los filtros de búsqueda LDAP.

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

Utilizando la plantilla de consulta, MongoDB sustituye {USER} con el nombre de usuario autenticado para consultar al servidor LDAP.

Por ejemplo, si un usuario se autentica como,CN=sam,CN=Users,DC=dba,DC=example,DC=com MongoDB crea una consulta LDAP basada en, sustituyendo queryTemplate el {USER} token por el nombre de usuario autenticado. El servidor de Active Directory realiza una búsqueda recursiva de grupos para cualquier grupo que incluya al usuario como miembro, ya sea directa o transitivamente. Según los grupos de Active Directory, el servidor de AD devuelve y. CN=dba,CN=Users,DC=example,DC=com CN=engineering,CN=Users,DC=example,DC=com

MongoDB asigna cada grupo devuelto del nombre distinguido a un rol en la admin base de datos. Para cada grupo mapeado nombre distinguido, si existe un rol en la base de datos admin cuyo nombre coincida exactamente con el nombre distinguido, MongoDB otorga al usuario los roles y privilegios asignados a ese rol.

La regla de coincidencia LDAP_MATCHING_RULE_IN_CHAIN requiere proporcionar el DN completo del usuario que se autentica. Dado que Kerberos requiere la autenticación con el del userPrincipalName usuario, debe transformar los nombres de usuario entrantes en DN security.ldap.userToDNMappingmediante. El siguiente paso proporciona instrucciones sobre cómo transformar los nombres de usuario entrantes para que sean compatibles queryTemplate con el.

10

En el archivo de configuración de MongoDB, configure para transformar el nombre de usuario proporcionado userToDNMapping por el usuario que realiza la autenticación en un DN de AD para queryTemplate admitir.

Ejemplo

La siguiente configuración utiliza userToDNMapping el match filtro de expresión regular para capturar el nombre de usuario proporcionado. MongoDB inserta el nombre de usuario capturado en la ldapQuery plantilla de consulta antes de ejecutar la consulta.

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

Debe modificar la configuración de ejemplo proporcionada para que coincida con su implementación. Por ejemplo, el ldapQuery DN base debe coincidir con el DN base que contiene sus entidades de usuario. Es posible que se requieran otras modificaciones para que su implementación de AD sea compatible.

Ejemplo

Un usuario alice@ENGINEERING.EXAMPLE.COM se autentica como. MongoDB aplica primero las transformaciones especificadas en. Según la configuración proporcionada, MongoDB captura el nombre de usuario en userToDNMapping la match etapa y ejecuta una consulta LDAP:

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

Basado en los usuarios de Active Directory configurados, el servidor AD debe devolver CN=alice,CN=Users,DC=engineering,DC=example,DC=com.

Luego, MongoDB ejecuta la consulta LDAP configurada en, reemplazando queryTemplate el {USER} token con el nombre de usuario CN=alice,CN=Users,DC=engineering,DC=example,DC=com transformado.

Importante

Si utiliza userToDNMapping substitution el parámetro de para transformar el nombre del grupo, el resultado de la sustitución debe ser una 4514 cadena de escape RFC.

11

MongoDB requiere credenciales para realizar consultas en el servidor AD.

Configure los siguientes ajustes en el archivo de configuración:

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

En los servidores MongoDB de Windows,security.ldap.bind.useOSDefaults puede true configurar a para usar las credenciales del usuario del sistema operativo en lugar de queryUser queryPasswordy.

El debe tener permiso para realizar todas las consultas LDAP en nombre de queryUser MongoDB.

12

Incluye opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a la implementación o si los miembros de la implementación se ejecutan en diferentes hosts, se debe especificar la configuración net.bindIp.

13

Inicie el servidor MongoDB con la opción, especificando la ruta al archivo de configuración creado durante este procedimiento. Si el servidor MongoDB está en ejecución, realice los preparativos necesarios para --config detenerlo.

Linux MongoDB Servers

En Linux, debe especificar la variable ambiental KRB5_KTNAME, especificando la ruta al archivo keytab para el servidor MongoDB.

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

Microsoft Windows MongoDB Servers

En Windows, debe iniciar el servidor MongoDB como la cuenta principal del servicio tal como se configuró anteriormente en el procedimiento:

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

Conéctese al servidor MongoDB y autentífiquese como un usuario cuya membresía de grupo directa o transitiva corresponde a un rol MongoDB en la admin base de userAdmin userAdminAnyDatabasedatos con, o un rol personalizado con privilegios equivalentes.

Utilice para autenticarse en el servidor MongoDB, configure las siguientes mongosh opciones:

Ejemplo

Anteriormente en este procedimiento, configuró el dn:CN=dba,CN=Users,DC=example,DC=com rol en la admin base de datos con los permisos necesarios. Este rol corresponde a un grupo de AD. Según los usuarios de AD configurados, puede autenticarse como el usuario sam@dba.example.com y ​​obtener los permisos necesarios.

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

Si no especificas la contraseña para la opción de línea de comandos -p, mongosh solicita la contraseña.

Windows Las implementaciones de MongoDB deben usar mongo.exe en lugar de mongosh.

Dados los usuarios de Active Directory configurados, el usuario se autentica correctamente y recibe los permisos adecuados.

Nota

Si desea autenticarse como un usuario no$external existente, configure --authenticationMechanism con un mecanismo de autenticación SCRAM (por ejemplo, SCRAM-SHA-1 o SCRAM-SHA-256). Esto requiere que el setParameter del servidor de MongoDB authenticationMechanisms incluya SCRAM-SHA-1 y/o SCRAM-SHA-256, según corresponda.

15

Para cada grupo en el servidor AD que desee utilizar para la autorización de MongoDB, debe crear un rol coincidente en la admin base de datos del servidor MongoDB.

Ejemplo

La siguiente operación crea un rol denominado según el DN del grupo de AD CN=PrimaryApplication,CN=Users,DC=example,DC=com y asigna roles y privilegios apropiados para ese grupo:

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

Dados los grupos de Active Directory configurados, MongoDB otorga a un usuario que se autentica como sam@DBA.EXAMPLE.COM o alice@ENGINEERING.EXAMPLE.COM el rol en readWrite la PrimaryApplication base de datos.

Nota

Para administrar roles en la admin base de datos, debe estar autenticado como un usuario userAdmin con admin en, userAdminAnyDatabase o un rol personalizado con privilegios equivalentes.

16

Si actualiza una instalación existente con usuarios configurados en la $external base de datos, debe cumplir los siguientes requisitos para cada usuario para garantizar el acceso después de configurar MongoDB para la autenticación Kerberos y la autorización de AD:

  • El usuario tiene un objeto de usuario correspondiente en el servidor AD.

  • El usuario es miembro de los grupos apropiados en el servidor AD.

  • MongoDB contiene los roles en la admin base de datos nombrados para los grupos de AD del usuario, de modo que el usuario autorizado conserva sus privilegios.

Ejemplo

El siguiente usuario existe en la base de datos $external:

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

Suponiendo que el usuario pertenece al grupo CN=marketing,CN=Users,DC=example,DC=com AD, la siguiente operación crea un rol coincidente con los privilegios adecuados:

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

Según el configurado, MongoDB autoriza a cualquier usuario que tenga membresía directa o transitiva en queryTemplate el CN=marketing,CN=Users,DC=example,DC=com grupo a realizar operaciones en read las web_analytics PrimaryApplication bases de datos y.

Importante

Al configurar un rol para un grupo de AD correspondiente, recuerde que todos los usuarios miembros de ese grupo pueden recibir los roles y privilegios asignados. Considere aplicar el principio de privilegio mínimo al configurar roles de MongoDB, grupos deAD o la pertenencia a grupos.

Si desea seguir permitiendo que los usuarios de$external bases de datos que no sean accedan a MongoDB, debe incluir el mecanismo de autenticación SCRAM (por ejemplo, SCRAM-SHA-1 SCRAM-SHA-256y/o) en la setParameter authenticationMechanisms opción de configuración.

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

Como alternativa, realice la transición de$external usuarios que no sean a AD siguiendo el procedimiento anterior.

Este procedimiento genera el siguiente archivo de configuración:

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"

Importante

La configuración de ejemplo proporcionada requiere modificaciones para que coincida con el esquema, la estructura de directorios y la configuración de AD. Es posible que también necesite opciones adicionales en el archivo de configuración para su implementación.

Para obtener más información sobre la configuración de roles y privilegios, consulte:

Después de completar los pasos de configuración, puede validar su configuración con la mongokerberos herramienta.

mongokerberos proporciona un método práctico para verificar la configuración de Kerberos de su plataforma para su uso con MongoDB y para comprobar que la autenticación Kerberos desde un cliente MongoDB funciona correctamente. Consulte la mongokerberos documentación de para obtener más información.

mongokerberos Está disponible únicamente en MongoDB Enterprise.

Volver

Solucionar problemas

En esta página