Docs Menu
Docs Home
/ /

Autorización LDAP en implementaciones autogestionadas

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 asignados y sus privilegios asociados.

El proceso de autorización 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 admita la 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 vincula al servidor LDAP especificado con utilizando las credenciales especificadas security.ldap.servers con security.ldap.bind.queryUser security.ldap.bind.queryPasswordy.

    MongoDB utiliza un enlace simple de manera predeterminada, pero puede utilizar el enlace en su sasl lugar si se configura en security.ldap.bind.method security.ldap.bind.saslMechanismsy.

  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 consulta 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, MongoDB vacía ldapUserCacheInvalidationInterval la $external caché. Antes de ejecutar operaciones posteriores realizadas por usuarios autorizados externamente, MongoDB recupera su membresía de grupo del 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 para su implementación de MongoDB.

MongoDB admite la autorización LDAP con los siguientes métodos de autenticación:

Con esta configuración, MongoDB utiliza la autorización LDAP, X.509 o Kerberos para autenticar las conexiones del cliente.

Al conectarse al servidor LDAP para autenticación/autorización, MongoDB, de forma predeterminada:

  • Utiliza agrupación 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 vinculados con libldap.

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

Para los binarios de MongoDB 4.2 Enterprise vinculados con libldap (como cuando se ejecuta en RHEL), el acceso a libldap está sincronizado, lo que genera algunos costos de rendimiento y latencia.

Para los binarios de MongoDB 4.2 Enterprise vinculados con libldap_r, no hay ningún cambio en el comportamiento respecto de las 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 admin base de datos, y el nombre de cada rol debe coincidir exactamente con el nombre distintivo (DN) de un grupo LDAP. Esto contrasta con la autorización administrada por MongoDB, que requiere la creación de usuarios en la $external base de datos.

Para administrar roles en el servidor MongoDB, autentíquese como un usuario cuya pertenencia a un grupo corresponda a un admin rol de base de datos con privilegios de administración de roles, como los proporcionados userAdmin por. Cree o actualice roles correspondientes a los DN de grupo LDAP para que los usuarios con pertenencia a 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 roles y privilegios administrativos. Un grupo LDAP para usuarios de marketing o análisis podría tener un rol con solo privilegios de lectura en ciertas bases de datos.

Importante

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

Si no existe ningún rol con privilegios de administración de roles Y no$external existe ningún usuario que no sea con estos privilegios, efectivamente no podrá realizar la administración de usuarios, ya que no se pueden modificar roles nuevos o existentes para reflejar adiciones o cambios en grupos o membresías de grupos en el servidor LDAP.

Para solucionar un escenario en el que no puede administrar roles en el servidor MongoDB, realice el siguiente procedimiento:

  1. Reiniciar 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. Autenticarse 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 apropiados

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

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

Para los conjuntos de réplicas, configure primero la autorización LDAP en los miembros secundarios y árbitros antes de configurar el principal. Esto también aplica a los conjuntos de réplicas de fragmentos o a los conjuntos de réplicas del servidor de configuración. Configure un miembro del conjunto de réplicas a la vez para mantener la mayoría de los miembros disponibles para escritura.

En clústeres fragmentados, debe configurar la autorización LDAP en los servidores de configuración para los usuarios a nivel de clúster. Opcionalmente, puede configurar la autorización LDAP en cada fragmento para los usuarios locales del fragmento.

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

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

Opción
Descripción
Requerido

Lista separada por comas y entre comillas de servidores LDAP en 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.

Puedes utilizar los siguientes tokens en la plantilla:

  • {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 la transformación LDAP, en la consulta LDAP.

Solomongodadmite este parámetro. mongosse remite a esta configuración 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.

queryPasswordÚselo con.

El usuario especificado debe tener los privilegios adecuados para admitir las consultas LDAP generadas desde el configurado.queryTemplate

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 sasl que se utilice 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 method menos sasl que configure en y necesite mecanismos SASL diferentes o adicionales.

Las implementaciones de Windows MongoDB pueden usar las credenciales del sistema operativo en lugar de queryUser y queryPassword para autenticar o vincular como cuando se conectan al servidor LDAP.

NO, a menos que reemplace queryUser queryPasswordy.

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 en DN LDAP.

Una vez configurada la autorización LDAP, reinicie o. El servidor ahora utiliza la autorización LDAP con mongod mongosX.,509 Kerberos o LDAP para autenticar las conexiones de los clientes.

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 consulta LDAP. Si MongoDB transformó el nombre de usuario usando, MongoDB reemplaza userToDNMapping el {USER} token con el nombre de usuario transformado al construir 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.

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 consulta LDAP debe cumplir con el formato definido en 4516RFC:

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

Considere la definición de cada componente, tal como se cita en 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 que se realizará en el servidor LDAP dado. Los alcances permitidos son "base" para una búsqueda de objeto base, "one" para una búsqueda de un nivel o "sub" para una búsqueda de subárbol.

El filter se utiliza para especificar el filtro de búsqueda que se aplicará a las entradas dentro del ámbito 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 consulta incluye un attribute, MongoDB asume que la consulta recupera los DN de los que esta entidad es miembro.

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

Actualmente, MongoDB ignora cualquier extensión especificada en la consulta LDAP.

Importante

Una descripción completa de la construcción de URL de consulta RFC4516 o LDAP está fuera del alcance de esta documentació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 dobles, para evitar que el shell interprete $external como una variable.

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

Si MongoDB adquiere un grupo cuyo DN coincide exactamente con el nombre de un rol existente, otorga al usuario autenticado los roles y privilegios asociados a dicho rol. Si MongoDB no puede asignar ninguno de los grupos devueltos a un rol, no le otorga ningún privilegio.

Nota

Laautenticación LDAP y Kerberos normalmente requiere la creación de usuarios en la $external base de datos. Si también utiliza LDAP para la autorización,no necesita crear usuarios en la $external base de datos. Solo necesita crear los roles correspondientes en la admin base de datos. Los $external usuarios se autentican en la base de datos.

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

Tras autenticar al usuario alice@dba.example.com en la $external base de datos, el servidor MongoDB realiza una consulta derivada del configurado para recuperar los grupos que incluyen al usuario autenticado como miembro. En este ejemplo, el servidor MongoDB recupera los siguientes DN de grupo para el query template usuario:

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

MongoDB asigna estos DN de grupo a roles en la base de datos admin. El primer DN de grupo coincide con el primer rol, y MongoDB otorga al usuario autenticado sus roles y privilegios. El segundo DN 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