Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Autenticación mediante Active Directory con LDAP nativo

Nota

A partir de MongoDB 8.0 y continuando en 9.0, la autenticación y autorización LDAP están obsoletas. LDAP se eliminará en una versión futura.

Para obtener información sobre métodos de autenticación alternativos, consulte Alternativas de autenticación LDAP.

MongoDB Enterprise proporciona soporte mediante librerías LDAP de plataforma para solicitudes de autenticación y autorización de proxy a un servicio especificado de Protocolo Ligero de Acceso a Directorios (LDAP), como Active Directory (AD).

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

Nota

Para los binarios de MongoDB 4.2 Enterprise vinculados contra libldap (como al ejecutarse en RHEL), el acceso a libldap está sincronizado, lo que genera algunos costos de rendimiento/latencia.

Para los binarios de MongoDB 4.2 Enterprise vinculados contra libldap_r, no hay cambios en el comportamiento respecto a versiones anteriores de MongoDB.

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 el vínculo operativo entre el servidor MongoDB y AD. Una descripción completa de SASL, los mecanismos de SASL, o los requisitos específicos de configuración de AD para un mecanismo SASL dado están más allá del alcance de este tutorial. Este tutorial asume un conocimiento previo de SASL y su tema relacionado.

Debe configurar la autenticación interna de nodos antes de poder configurar la autenticación o autorización LDAP para un clúster.

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

Para realizar este procedimiento en su propio servidor MongoDB, debe modificar los procedimientos dados con respecto a su propia infraestructura específica, especialmente la configuración del Active Directory, la construcción de AD consultas o la gestió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.

Para usar sesiones de cliente y garantías de coherencia causal con usuarios de autenticación $external (usuarios Kerberos, LDAP o X.509), los nombres de usuario no pueden superar los 10k bytes.

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 una contraseña para realizar consultas en el servidor AD. Las credenciales proporcionadas deben tener privilegios suficientes en el servidor 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, los dispositivos mongod o mongos requieren acceso al certificado de la Autoridad de Certificación (CA) del servidor AD.

En Linux, especifique los certificados CA del servidor AD mediante 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, carga los certificados de la Autoridad de Certificación (CA) del servidor AD con la herramienta de gestión de credenciales de la plataforma. La herramienta exacta de gestión de credenciales depende de la versión de Windows. Para utilizar la herramienta, consulte la documentación para tu 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

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, debe reemplazar mongosh por mongo.exe.

3

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

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

Dado los grupos disponibles de Active Directory, la siguiente operación:

  • Crea un rol con el nombre del grupo de AD CN=dba,CN=Users,DC=example,DC=com, y

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

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

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

4

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 para Linux) Si esto es una nueva implementación y se usó el gestor de paquetes de la plataforma para instalar MongoDB Enterprise, la instalación incluye el archivo de configuración por defecto /etc/mongod.conf. Utilice ese archivo de configuración por defecto o haga una copia de ese archivo para trabajar.

  • 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.

5

En el archivo de configuración de MongoDB, establezca security.ldap.servers con el host y el puerto del servidor AD. Si su infraestructura de AD incluye varios servidores AD para fines de replicación, especifique el host y el puerto de los servidores como una lista separada por comas en security.ldap.servers.

También debes habilitar la autenticación LDAP configurando security.authorization en enabled y setParameter authenticationMechanisms en PLAIN

Ejemplo

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

security:
authorization: "enabled"
ldap:
servers: "activedirectory.example.net"
setParameter:
authenticationMechanisms: 'PLAIN'

MongoDB debe vincularse al servidor AD para realizar consultas. Por defecto, MongoDB utiliza el mecanismo de autenticación sencilla para vincularse al servidor AD.

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

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

6

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} espacio reservado para sustituir el nombre de usuario autenticado en la URL de la query 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.

Nota

Este tutorial no incluye una descripción completa de RFC4515, RFC4516 ni de las consultas de Active Directory. El ejemplo queryTemplate que se presenta aquí es solo ilustrativo y podría no ser aplicable a su implementación específica de Active Directory.

Ejemplo

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

Advertencia

Si el bosque de AD contiene un gran número de grupos, el filtro recursivo member:1.2.840.113556.1.4.1941 puede provocar una degradación significativa del rendimiento.

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 en función de la queryTemplate, sustituyendo el token {USER} por el nombre de usuario autenticado o transformado. El servidor de Active Directory realiza una búsqueda recursiva de grupos para cualquier grupo que incluya al usuario como nodo directa o transitivamente. Según los grupos de Active Directory, el AD servidor devuelve los siguientes grupos:

  • CN=dba,CN=Users,DC=example,DC=com

  • CN=engineering,CN=Users,DC=example,DC=com

  • CN=PrimaryApplication,CN=Users,DC=example,DC=com

MongoDB asigna cada DN de grupo devuelto a un rol en la base de datos admin. Para cada DN de grupo asignado, si existe un rol en la base de datos admin cuyo nombre coincide exactamente con el DN, 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. Si los usuarios se autentican utilizando un formato de nombre de usuario diferente, como su user principal name, debe transformar los nombres de usuario entrantes en DN utilizando security.ldap.userToDNMapping.

7

Si tus usuarios se autentican con un nombre de usuario que no es un nombre distinguido de LDAP completo, es posible que debas transformar el nombre de usuario para apoyar la autenticación o autorización de LDAP. MongoDB utiliza el nombre de usuario transformado tanto para la autenticación como para la autorización.

En el archivo de configuración de MongoDB, establezca userToDNMapping para transformar el nombre de usuario proporcionado por el usuario que se autentica en un DN de AD para admitir queryTemplate.

Ejemplo

Dada la queryTemplate configurada, los usuarios deben autenticarse con su nombre distinguido LDAP completo. Si los usuarios, en su lugar, se autentican utilizando su userPrincipalName, entonces se debe aplicar una transformación para convertir el nombre de usuario proporcionado en un nombre distinguido LDAP completo.

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})"
}
]'

El servidor de Active Directory devuelve el nombre distinguido completo de LDAP asociado al objeto de usuario con un userPrincipalName coincidente. Luego, MongoDB puede utilizar este nombre de usuario transformado para la autenticación y la autorización.

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)

En función de los usuarios de Active Directory configurados, el servidor AD debería devolver CN=alice,CN=Users,DC=engineering,DC=example,DC=com.

MongoDB ejecuta a continuación la query LDAP configurada en queryTemplate, sustituyendo el token {USER} por el nombre de usuario transformado CN=alice,CN=Users,DC=engineering,DC=example,DC=com.

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 escapada RFC.

8

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 MongoDB de Windows, puede configurar security.ldap.bind.useOSDefaults a true para usar las credenciales del usuario del sistema operativo en lugar de queryUser y queryPassword.

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

9

Agrega cualquier opción de configuración adicional necesaria para tu implementación. Por ejemplo, puedes especificar tu storage.dbPath deseado o cambiar el número net.port por defecto.

mongod y mongos se vinculan a localhost por defecto. Si los nodos de su implementación se ejecutan en distintos hosts o si desea que clientes remotos se conecten a su implementación, debe especificar el ajuste net.bindIp.

10

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.

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

Las implementaciones de MongoDB en Windows deben usar mongod.exe en lugar de mongod.

11

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 rol dn:CN=dba,CN=Users,DC=example,DC=com en la base de datos admin con los permisos necesarios. Este rol corresponde a un grupo de Active Directory. Según los usuarios de Active Directory configurados, puede autenticarse como el usuario sam@dba.example.com y obtener los permisos necesarios.

mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanism 'PLAIN' --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.

Las implementaciones de MongoDB en Windows 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 deseas autenticarte como un usuario existente que no sea$external, establece --authenticationMechanism al mecanismo de autenticación SCRAM (por ejemplo, SCRAM-SHA-1 o SCRAM-SHA-256 según corresponda). Esto requiere que el setParameter authenticationMechanisms del servidor de MongoDB incluya SCRAM-SHA-1 y/o SCRAM-SHA-256.

12

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

Ejemplo

La siguiente operación crea un rol con el nombre del DN del grupo de AD CN=PrimaryApplication,CN=Users,DC=example,DC=com, asignando 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" }
]
}
)

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 gestionar roles en la base de datos admin, debes estar autenticado como un usuario con userAdmin en admin, userAdminAnyDatabase o con un rol personalizado con privilegios equivalentes.

13

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

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

  • El usuario tiene membresía en los grupos apropiados 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 mantiene 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 de AD CN=marketing,CN=Users,DC=example,DC=com, 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. Considere aplicar el principio de mínimo privilegio al configurar roles de MongoDB, grupos de AD o membresías de grupo.

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. Por ejemplo:

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

Alternativamente, cambia los usuarios que no sean$external 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: "PLAIN"

La configuración de muestra dada requiere ser modificada para ajustarse a su esquema de Active Directory, estructura del directorio y configuración. También puede requerir opciones adicionales de archivo de configuración para su implementación.

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