Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
Kerberos
/ / / / /

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

MongoDB Enterprise permite consultar un servidor LDAP para los grupos LDAP a los que pertenece un usuario autenticado. MongoDB asigna los nombres distinguidos de LDAP (DN) de cada grupo devuelto a roles en el admin Base de datos. MongoDB autoriza al usuario en función de los roles mapeados y sus privilegios asociados. Consulta Autorizacion LDAP para 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ízate minuciosamente con los siguientes temas antes de continuar:

Una descripción completa de AD está fuera del alcance de este tutorial. Este tutorial asume 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.

En los sets de réplicas y clústeres, asegúrate de que tu configuración utilice nombres de dominio completamente calificados (FQDN) en lugar de direcciones IP o nombres de host no calificados. Debe usar el FQDN para GSSAPI a fin de resolver correctamente los dominios de Kerberos y permitirle conectarse.

Para comprobar que está utilizando MongoDB Enterprise, pase la opción de línea de comandos --version a mongod o a mongos:

mongod --version

En la salida de este comando, busca la string modules: subscription o modules: enterprise para confirmar que estás usando los binarios de MongoDB Enterprise.

Este tutorial explica cómo configurar MongoDB para la autenticación Kerberos y la autorización 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.

Por defecto, MongoDB crea una conexión TLS/SSL al vincularse al servidor AD. Esto requiere configurar el host del servidor MongoDB para tener acceso a los certificados de la Autoridad de Certificación (CA) del servidor AD.

Este tutorial proporciona instrucciones para las configuraciones del host requeridas.

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

En este tutorial se utilizan los siguientes objetos de ejemplo AD 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 contraseña para realizar consultas en el AD servidor. Las credenciales provistas deben tener privilegios suficientes en el servidor de AD para admitir consultas relacionadas con security.ldap.userToDNMapping o security.ldap.authz.queryTemplate.

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 mongos en el clúster fragmentado estén al menos en MongoDB 3.4.0 o posterior.

1

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

En Linux, especifica los certificados CA del servidor AD a través de la opción TLS_CACERT o TLS_CACERTDIR en el archivo ldap.conf.

El gestor de paquetes de la plataforma crea el archivo ldap.conf al instalar la dependencia libldap de MongoDB Enterprise. Para obtener 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

Configurar transportSecurity en none transmite información en texto plano, incluidas las credenciales de usuario, entre MongoDB y el servidor AD.

2

Para los servidores de MongoDB que se ejecutan en el sistema operativo Windows, debes 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 mongod se ejecuta como un servicio llamado mongodb en mongodbserver.example.com con el nombre de cuenta de servicio mongodb_dev@example.com, el comando para asignar el SPN sería el siguiente:

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

Nota

Windows Server 2003 no es compatible con setspn.exe -S. Para obtener documentación completa sobre setspn.exe, consulta 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 de MongoDB usando mongosh usando las opciones --host y --port.

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

Si tu servidor de MongoDB actualmente aplica la autenticación, debes autenticarte en la admin base de datos como un usuario con privilegios de gestión de roles, como los proporcionados por userAdmin o userAdminAnyDatabase. Incluye el --authenticationMechanism adecuado para el mecanismo de autenticación configurado del servidor de MongoDB.

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

Nota

Para implementaciones de MongoDB en Windows, debes reemplazar mongosh con mongo.exe

5

Para gestionar usuarios de MongoDB usando AD, es necesario crear al menos un rol en la base de datos admin que pueda crear y gestionar roles, como los que proporciona 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 para el grupo 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 rol userAdmin para cada base de datos sobre la que el usuario deba tener privilegios administrativos de usuario. Estos roles proporcionan los privilegios necesarios para la creación y gestión de roles.

Importante

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

6

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

  • 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 un archivo de ese tipo, cree un archivo vacío con la extensión .conf y trabaje a partir de ese nuevo archivo de configuración.

7

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

Ejemplo

Para conectarte a un servidor AD ubicado en activedirectory.example.net, incluye 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, configure security.ldap.authz.queryTemplate en una RFC4516 plantilla de URL de query LDAP con formato.

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

Una descripción completa de RFC4515, RFC4516, o AD query está fuera del alcance de este tutorial. El queryTemplate proporcionado en este tutorial es solo un ejemplo y puede que no sea aplicable para tu implementación específica de AD.

Ejemplo

La siguiente plantilla de query devuelve cualquier grupo que incluya a {USER} como miembro, siguiendo membresías de grupo recursivas. Esta query LDAP asume que los objetos de grupo rastrean la membresía de los usuarios almacenando el nombre distinguido completo del usuario (DN) usando el atributo member. La query incluye el AD OID de regla de coincidencia específico 1.2.840.113556.1.4.1941 para LDAP_MATCHING_RULE_IN_CHAIN. Esta regla de correspondencia 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}))"

Usando la plantilla de query, MongoDB sustituye {USER} por el nombre de usuario autenticado para consultar el servidor LDAP.

Por ejemplo, un usuario se autentica como CN=sam,CN=Users,DC=dba,DC=example,DC=com. MongoDB crea una query LDAP basada en el queryTemplate, sustituyendo el token {USER} por el nombre de usuario autenticado. El servidor de Active Directory realiza una búsqueda recursiva de grupos para cualquier grupo que liste al usuario como nodo, ya sea de forma directa o transitiva. Según los grupos de Active Directory, el servidor de AD devuelve CN=dba,CN=Users,DC=example,DC=com y 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 correspondencia LDAP_MATCHING_RULE_IN_CHAIN requiere proporcionar el nombre distinguido completo del usuario autenticado. Dado que Kerberos requiere autenticación con el userPrincipalName del usuario, debes transformar los nombres de usuario entrantes en DNs usando security.ldap.userToDNMapping. El siguiente paso ofrece orientación sobre cómo transformar los nombres de usuario entrantes para admitir la queryTemplate.

10

En el archivo de configuración de MongoDB, configura userToDNMapping para transformar el nombre de usuario proporcionado por el usuario que se está autenticando en un nombre distinguido AD para habilitar el queryTemplate.

Ejemplo

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

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

Debes modificar la configuración de muestra proporcionada para que coincida con tu implementación. Por ejemplo, la nombre distinguido base ldapQuery debe coincidir con la nombre distinguido base que contiene tus entidades de usuario. Pueden ser necesarias otras modificaciones para admitir la implementación de AD.

Ejemplo

Un usuario se autentica como alice@ENGINEERING.EXAMPLE.COM. MongoDB primero aplica cualquier transformación especificada en userToDNMapping. Según la configuración proporcionada, MongoDB captura el nombre de usuario en la etapa match y ejecuta una query 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 el parámetro substitution de userToDNMapping para transformar el nombre del grupo, then resultado de la sustitución debe ser una string escapada RFC4514.

11

MongoDB requiere credenciales para realizar consultas en el servidor AD.

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

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

En los servidores de MongoDB en Windows, puedes configurar security.ldap.bind.useOSDefaults en true para usar las credenciales del sistema operativo en lugar de queryUser y queryPassword.

El queryUser debe tener permiso para realizar todas las queries LDAP en nombre de 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

Inicia el servidor MongoDB con la opción --config, especificando la ruta al archivo de configuración creado durante este procedimiento. Si el servidor MongoDB está actualmente en ejecución, realiza los preparativos adecuados para detener el servidor.

Linux MongoDB Servers

En Linux, debe especificar la variable de entorno KRB5_KTNAME, indicando la ruta al archivo keytab para el servidor de MongoDB.

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

Microsoft Windows MongoDB Servers

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

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

Conéctate al servidor de MongoDB, autenticándote como un usuario cuya membresía directa o transitiva en un grupo corresponda a un rol de MongoDB en la base de datos admin con userAdmin, userAdminAnyDatabase o un rol personalizado con privilegios equivalentes.

Uso mongosh para autenticarse en el servidor de MongoDB, establece las siguientes 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 con éxito y recibe los permisos correspondientes.

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 nombre distinguido del grupo AD CN=PrimaryApplication,CN=Users,DC=example,DC=com, asignando roles y privilegios apropiados a ese grupo:

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

Dado el grupo de directorio activo configurado, MongoDB otorga a un usuario que se autentica como sam@DBA.EXAMPLE.COM o alice@ENGINEERING.EXAMPLE.COM el rol de readWrite en la base de datos PrimaryApplication.

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 está actualizando una instalación existente con usuarios configurados en la base de datos $external, debe cumplir con los siguientes requisitos para cada usuario para garantizar el acceso después de configurar MongoDB para la autenticación de Kerberos y la autorización AD:

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

  • El usuario tiene membresía en los grupos correspondientes en el servidor AD.

  • MongoDB contiene los roles en la base de datos admin nombrados para los grupos AD del usuario, de modo que el usuario autorizado conserve 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" }
]
}
)

En base a la queryTemplate configurada, MongoDB autoriza a cualquier usuario que tenga una membresía directa o transitiva en el grupo CN=marketing,CN=Users,DC=example,DC=com a realizar operaciones read en las bases de datos web_analytics y PrimaryApplication.

Importante

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

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

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 muestra proporcionada requiere modificaciones para coincidir con tu esquema de AD, estructura de directorio y configuración. También puedes requerir opciones de archivo de configuración adicionales para tu implementación.

Para obtener más información sobre cómo configurar roles y privilegios, consulte:

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

mongokerberos proporciona un método conveniente para comprobar la configuración de Kerberos de la plataforma con MongoDB y para verificar que la autenticación Kerberos de un cliente MongoDB funciona como se espera. Consulta la documentación de mongokerberos para obtener más información.

mongokerberos está disponible solo en MongoDB Enterprise.

Volver

Solucionar problemas

En esta página