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
/ /

Autorización LDAP en implementaciones autogestionadas

Nota

A partir de MongoDB 8.0, la autenticación y autorización de LDAP están obsoletas. LDAP está disponible y continuará operando sin cambios durante toda la vida útil de MongoDB 8. LDAP se eliminará en una futura versión principal.

Para obtener más detalles, consulte Desuso de LDAP.

MongoDB Enterprise permite consultar un servidor LDAP para conocer los grupos LDAP a los que pertenece el usuario autenticado. MongoDB asigna los nombres distinguidos (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.

El proceso de autorizacion LDAP se resume a continuación:

  1. Un cliente se conecta a MongoDB y realiza la autenticación con cualquier mecanismo de autenticación que admite autenticación externa.

    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.

  2. MongoDB se conecta al servidor LDAP especificado con security.ldap.servers utilizando las credenciales especificadas con security.ldap.bind.queryUser y security.ldap.bind.queryPassword.

    MongoDB utiliza el enlace simple por defecto, pero puede utilizar el enlace sasl en su lugar si se configura en security.ldap.bind.method y security.ldap.bind.saslMechanisms.

  3. MongoDB construye una consulta LDAP utilizando y consulta al servidor LDAP la membresía del grupo del usuario security.ldap.authz.queryTemplate autenticado.

    MongoDB puede usar la opción para transformar el nombre de usuario para admitir la plantilla de security.ldap.userToDNMapping consulta.

  4. El servidor LDAP evalúa la query y devuelve la lista de grupos a los que pertenece el usuario autenticado.

  5. MongoDB autoriza al usuario a realizar acciones en el servidor asignando el nombre distintivo (DN) de cada grupo devuelto a un rol en la admin base de datos. Si un DN de grupo devuelto coincide exactamente con el nombre de un rol existente en la admin base de datos, MongoDB otorga al usuario los roles y privilegios asignados a dicho rol. Consulte Roles de MongoDB para la autorización LDAP para obtener más información.

  6. El cliente puede realizar acciones en el servidor MongoDB que requieran los roles o privilegios otorgados al usuario autenticado.

  7. En un intervalo definido por ldapUserCacheInvalidationInterval, MongoDB vacía la caché $external. Antes de ejecutar operaciones subsiguientes realizadas por usuarios autorizados externamente, MongoDB vuelve a adquirir su membresía de grupo desde el servidor LDAP.

Una descripción completa de LDAP queda fuera del alcance de esta documentación. Esta página presupone conocimientos previos de LDAP.

Esta documentación solo describe la autorización LDAP de MongoDB y no sustituye a otros recursos sobre LDAP. Le recomendamos familiarizarse completamente con LDAP y sus temas relacionados antes de configurar la autenticación LDAP.

MongoDB puede proporcionar servicios profesionales para la configuración óptima de la autorización LDAP en tu implementación de MongoDB.

MongoDB es compatible con la autorización LDAP mediante los siguientes métodos de autenticación:

Con esta configuración, MongoDB utiliza autorización LDAP, X.509 o Kerberos para autenticar las conexiones de los clientes.

Al conectarse al servidor LDAP para autenticación/autorización, MongoDB, por defecto:

  • Utiliza agrupamiento de conexiones si se ejecuta:

    • en Windows o

    • en Linux, donde los binarios de MongoDB Enterprise están vinculados con libldap_r.

  • No utiliza agrupación de conexiones si se ejecuta:

    • en Linux, donde los binarios de MongoDB Enterprise están enlazados con libldap.

Para cambiar el comportamiento de agrupamiento de conexiones, actualice el parámetro ldapUseConnectionPool.

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.

Con la autorización LDAP, la creación y gestión de usuarios se realiza en el servidor LDAP. MongoDB requiere la creación de roles en la base de datos admin, con el nombre de cada rol coincidiendo exactamente con un nombre distinguido (DN) de grupo LDAP. Esto es en contraste con la autorización gestionada por MongoDB, que requiere crear usuarios en la base de datos $external.

Para gestionar roles en el servidor de MongoDB, autentifícate como un usuario cuya pertenencia a un grupo corresponda a un rol de base de datos admin con privilegios de administración de roles, como los proporcionados por userAdmin. Cree o actualice roles que correspondan a los DN de grupo de LDAP, de modo que los usuarios que sean miembros de ese grupo reciban los roles y privilegios adecuados.

Por ejemplo, un grupo LDAP para administradores de bases de datos podría tener un rol con funciones y privilegios administrativos. Un grupo de LDAP para usuarios de marketing o análisis puede tener un rol con solo privilegios de lectura en ciertas bases de datos.

Importante

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

Si no existe ningún rol con privilegios de administración de roles Y ningún usuario que no sea$external con estos privilegios, de hecho no puedes realizar la gestión de usuarios, ya que no se puede modificar ningún rol nuevo o existente para reflejar adiciones o cambios en los grupos o la membresía de grupos en el servidor LDAP.

Para remediar un escenario en el que no se puedan gestionar roles en el servidor de MongoDB, realiza el siguiente procedimiento:

  1. Reinicia el servidor MongoDB sin autenticación ni autorización LDAP

  2. Cree un rol en la base de datos admin cuyo nombre corresponda al nombre distintivo del grupo LDAP correspondiente. Al elegir un DN de grupo, considere cuál es el más adecuado para la administración de la base de datos.

  3. Reinicie el servidor MongoDB con autenticación y autorización LDAP

  4. Autentícate como usuario con membresía en el grupo correspondiente al rol administrativo creado.

Un servidor MongoDB que utiliza LDAP para la autorización impide el acceso a los usuarios existentes en la base de datos $external. Si hay usuarios en la base de datos $external, debe cumplir los siguientes requisitos para cada usuario de la base de datos $external para garantizar el acceso continuo:

  • El usuario tiene un objeto de usuario correspondiente en el servidor LDAP

  • El objeto de usuario tiene membresía en los grupos LDAP correspondientes

  • MongoDB tiene roles en la base de datos admin nombrados para los grupos LDAP del usuario, de modo que los roles y privilegios concedidos son idénticos a los concedidos al usuario no-$external.

Si desea seguir permitiendo el acceso de usuarios que no están en la base de datos $external, asegúrese de que el parámetro authenticationMechanisms incluya SCRAM-SHA-1 y/o SCRAM-SHA-256 según corresponda. Alternativamente, aplique los requisitos mencionados anteriormente para trasladar a esos usuarios a la autorización LDAP.

Para sets de réplicas, configura la autorizacion LDAP en los miembros secundario y árbitro antes de configurar el primario. Esto también se aplica a los conjuntos de réplicas de particiones o a los conjuntos de réplicas de servidores de configuración. Configura un miembro del set de réplicas a la vez para mantener una mayoría de miembros para la disponibilidad de guardar.

En clústeres particionados, debes configurar la autorización LDAP en los servidores de configuración para los usuarios a nivel del clúster. Opcionalmente, puedes configurar la autorizacion LDAP en cada partición para los usuarios locales del fragmento.

Debe configurar los siguientes ajustes para utilizar la autorización LDAP:

Para usar LDAP para la autorización a través de bibliotecas del sistema operativo, especifique la siguiente configuración como parte de su archivo de mongos mongod configuración o archivo de configuración:

Opción
Descripción
Requerido

Lista separada por comas de servidores LDAP con comillas en el formato host[:port].

Puedes anteponer a los servidores LDAP los prefijos srv: y srv_raw:.

Si la cadena de conexión especifica "srv:<DNS_NAME>", mongod verifica que "_ldap._tcp.gc._msdcs.<DNS_NAME>" existe para que SRV sea compatible con Active Directory. Si no se encuentra, mongod verifica que "_ldap._tcp.<DNS_NAME>" existe para SRV. Si no se encuentra un registro SRV, mongod advierte que se use "srv_raw:<DNS_NAME>" en cambio.

Si su cadena de conexión especifica "srv_raw:<DNS_NAME>", mongod realiza una búsqueda de un registro SRV para "<DNS NAME>".

Una plantilla de URL de consulta LDAP con formato RFC4515 y RFC, ejecutada por MongoDB para obtener los grupos LDAP a los que4516 servers pertenece el usuario. La consulta es relativa al host o hosts especificados en.

Puede utilizar los siguientes tokens en el modelo:

  • {USER}
    Sustituye el nombre de usuario autenticado o el nombre de usuario de transformed en la query LDAP.
  • {PROVIDED_USER}
    Sustituye el nombre de usuario proporcionado, es decir, antes de la autenticación o transformación LDAP, en la query LDAP.

Solo mongod admite este parámetro. mongos se remite a esta configuración como se configura en sus servidores de configuración

La identidad con la que se conecta y ejecuta operaciones y queries un servidor MongoDB en un servidor LDAP.

Usar con queryPassword.

El usuario especificado debe tener los privilegios adecuados para soportar las queries LDAP generadas a partir de la queryTemplate.configurada.

La contraseña utilizada para vincularse a un servidor LDAP cuando se queryUser utiliza.

Se utiliza para especificar el método que mongod o utilizan para autenticarse o vincularse al servidor LDAP.mongos Especifique sasl para usar uno de los protocolos SASL definidos security.ldap.bind.saslMechanisms en.

Se establece por defecto en simple.

NO, a menos que utilice sasl para vincularse al servidor LDAP.

Se utiliza para especificar los mecanismos SASL mongod que o pueden usar al autenticarse o vincularse al servidor LDAP. MongoDB y el servidor LDAP deben coincidir en al menos un mecanismo mongos SASL.

Se establece por defecto en DIGEST-MD5.

NO, a menos que configure method a sasl, y necesite mecanismos SASL diferentes o adicionales.

Las implementaciones de MongoDB en Windows pueden usar las credenciales del sistema operativo en lugar de queryUser y queryPassword para autenticar o vincularse al conectarse al servidor LDAP.

NO, a menos que esté reemplazando queryUser y queryPassword.

Dependiendo de su queryTemplate, es posible que el nombre de usuario de cliente autenticado requiera una transformación para soportar la URL de consulta LDAP. userToDNMapping permite que MongoDB transforme los nombres de usuario entrantes.

NO, a menos que los nombres de usuario del cliente requieran transformación a DNs de LDAP.

Cuando hayas configurado la autorización LDAP, reinicia mongod o mongos. El servidor ahora utiliza la autorización LDAP con X.509, Kerberos o LDAP para autenticar las conexiones del cliente.

MongoDB usa para security.ldap.authz.queryTemplate crear una URL de consulta LDAP con formato RFC. En la plantilla, puede4516 usar:

  • {USER} marcador de posición para sustituir el nombre de usuario autenticado en la URL de query LDAP. Si MongoDB transformó el nombre de usuario usando userToDNMapping, MongoDB reemplaza el token {USER} por el nombre de usuario transformado al construir la URL de 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.

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

Ejemplo

La siguiente plantilla de consulta devuelve todos los grupos enumerados en el atributo memberOf del objeto de usuario LDAP. Esta consulta presupone la existencia del atributo memberOf; su implementación LDAP específica podría utilizar un atributo o una metodología diferente para el seguimiento de la pertenencia a grupos. Esta consulta también presupone que el usuario se autentica utilizando su DN LDAP completo como nombre de usuario.

"{USER}?memberOf?base"

La URL de la query LDAP debe cumplir con el formato definido en RFC4516:

[ dn [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

Considere la definición de cada componente, como se cita en el RFC4516:

El dn es un nombre distintivo LDAP que utiliza el formato de cadena descrito en RFC.4514 Identifica el objeto base de la búsqueda LDAP o el objetivo de una operación que no sea de búsqueda.

La construcción attributes se utiliza para indicar qué atributos deben devolverse de la entrada o entradas.

La construcción scope se utiliza para especificar el alcance de la búsqueda a realizar en el servidor LDAP determinado. Los ámbitos permitidos son "base" para una búsqueda de objeto base, "uno" para una búsqueda a un nivel o "sub" para una búsqueda en subárbol.

El filter se usa para especificar el filtro de búsqueda a aplicar a las entradas dentro del alcance especificado durante la búsqueda. Tiene el formato especificado en [RFC4515].

La construcción extensions proporciona a la URL LDAP un mecanismo de extensibilidad, lo que permite ampliar las capacidades de la URL en el futuro.

Si la query incluye un attribute, MongoDB asume que la query recupera las DNs de las que esta entidad es nodo.

Si la query no incluye un atributo, MongoDB supone que la query recupera todas las entidades de las que el usuario es miembro.

MongoDB actualmente ignora cualquier extensión especificada en la query LDAP.

Importante

Una descripción completa de la RFC4516 o de la construcción de una URL de query LDAP está fuera del alcance de esta descripción.

Los siguientes tutoriales contienen procedimientos para conectarse a un servidor LDAP a través de las bibliotecas LDAP del sistema operativo:

Al utilizar LDAP para la autorización, los usuarios que se conectan a través de mongosh deben:

Incluye el --host y --port del servidor de MongoDB, junto con cualquier otra opción relevante para tu implementación.

Por ejemplo, la siguiente operación se autentica en un servidor MongoDB que se ejecuta con autenticación y autorización LDAP:

mongosh --username alice@dba.example.com --password --authenticationDatabase '$external' --authenticationMechanism "PLAIN" --host "mongodb.example.com" --port 27017

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

Importante

El argumento $external debe colocarse entre comillas simples, no entre comillas double, para evitar que el shell interprete $external como una variable.

MongoDB asigna cada nombre distinguido de grupo (DN) devuelto por el al LDAP query a un rol en la admin base de datos.

Si MongoDB adquiere un grupo cuyo nombre distinguido coincide exactamente con el nombre de un rol existente, MongoDB otorga al usuario autenticado los roles y privilegios asociados con ese rol. Si MongoDB no puede asignar ninguno de los grupos devueltos a un rol, MongoDB no otorga privilegios al usuario.

Nota

La autenticación LDAP y kerberos normalmente requiere crear usuarios en la base de datos $external. Si también utiliza LDAP para la autorización, no necesita crear usuarios en la base de datos de $external. Solo necesitas crear los roles apropiados en la base de datos admin. Los usuarios aún se autentican en la base de datos $external.

Importante

Si está utilizando LDAP para autorización y los DN de su grupo LDAP contienen 4514 secuencias de escape RFC, los roles que cree en la admin base de datos también deben tener secuencias de escape según4514 RFC.

Ejemplo

Una base de datos tiene los siguientes roles configurados en la base de datos admin:

{
role: "CN=dba,CN=Users,DC=example,DC=com",
privileges: [],
roles: [ "dbAdminAnyDatabase", "clusterAdmin" ]
}
{
role: "CN=analytics,CN=Users,DC=example,DC=com"
privileges: [],
roles: [
{ role : "read", db : "web_statistics" },
{ role : "read", db : "user_statistics" }
]
}

Después de autenticar a un usuario alice@dba.example.com contra la base de datos $external, el servidor MongoDB realiza una query derivada de la query template configurada para recuperar los grupos que incluyen al usuario autenticado como miembro. En este ejemplo, el servidor de MongoDB recupera los siguientes DNs de grupo para el usuario:

dn:CN=dba,CN=Users,dc=example,dc=com
dn:CN=admin,CN=Users,dc=example,dc=com

MongoDB asigna estos DNs de grupo a roles en la base de datos admin. El primer nombre distinguido de grupo coincide con el primer rol, y MongoDB otorga al usuario autenticado sus roles y privilegios. El segundo nombre distinguido de grupo no coincide con ningún rol en el servidor, por lo que MongoDB no otorga permisos adicionales.

Un nuevo usuario bob@analytics.example.com se autentica en la base de datos $external. El servidor MongoDB repite el proceso de query, utilizando el nombre de usuario proporcionado en la plantilla de query. En este ejemplo, el servidor MongoDB recupera los siguientes DN de grupo para el usuario:

dn:cn=analytics,CN=Users,dc=example,dc=com

MongoDB asigna estos DNs de grupo a roles en la base de datos admin y otorga al usuario autenticado los roles y privilegios del segundo rol.

Un nuevo usuario workstation@guest.example.com se autentica en la base de datos $external. El servidor MongoDB repite el proceso de query, utilizando el nombre de usuario proporcionado en la plantilla de query. En este ejemplo, el servidor MongoDB recupera los siguientes DN de grupo para el usuario:

dn:cn=guest,CN=Users,dc=example,dc=com

MongoDB asigna el grupo a un rol en la base de datos admin y, como no existen roles coincidentes, no le otorga al usuario permisos adicionales.

Volver

Acceso a nivel de la colección

En esta página