Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Autenticação de proxy LDAP

Nesta página

  • Considerações
  • Autenticação LDAP por meio das bibliotecas LDAP do sistema operacional
  • Autenticação LDAP via saslauthd
  • Conectar a um servidor MongoDB via autenticação LDAP

MongoDB Enterprise permite solicitações de autenticação de proxy para um serviço Lightweight Directory Access Protocol (LDAP).

O MongoDB suporta conexão simples e SASL com servidores LDAP:

Via
Descrição
Bibliotecas do sistema operacional

A partir da versão 3.4, o MongoDB permite ligação a um servidor LDAP por meio de bibliotecas de sistemas operacionais.

Isso permite que servidores MongoDB no Linux e Windows usem um servidor LDAP para autenticação.

Nas versões anteriores, o MongoDB no Microsoft Windows não conseguia se conectar a servidores LDAP.

saslauthd

Os servidores MongoDB no Linux suportam a ligação a um servidor LDAP através do daemon saslauthd .

Não disponível para MongoDB no Windows.

Uma descrição completa do LDAP está além do escopo desta documentação. Esta página pressupõe conhecimento prévio do LDAP.

Esta documentação descreve apenas a autenticação LDAP do MongoDB e não substitui outros recursos no LDAP. Recomendamos que você se familiarize completamente com o LDAP e com o assunto relacionado a ele antes de configurar a autenticação LDAP.

O MongoDB pode fornecer serviços profissionais para a configuração ideal da autenticação LDAP para MongoDB deployment.

A partir da versão 4.2.0, ao se conectar ao servidor LDAP para autenticação/autorização, o MongoDB, por padrão, é conectado ao servidor LDAP para autenticação/autorização:

  • Usa pool de conexões se executado:

    • no Windows ou

    • no Linux, onde os binários MongoDB Enterprise estão vinculados a libldap_r.

  • Não usa pool de conexões se executado:

    • no Linux, onde os binários MongoDB Enterprise estão vinculados ao libldap.

Para alterar o comportamento do agrupamento de conexão, atualize o parâmetro ldapUseConnectionPool.

Importante

O diretório pai do arquivo de soquete de domínio Unix do saslauthd especificado para security.sasl.saslauthdSocketPath ou --setParameter saslauthdPath deve conceder permissões de leitura e execução (r-x) para:

  • O usuário iniciando o mongod ou mongos, ou

  • Um grupo ao qual esse usuário pertence.

O mongod ou mongos não pode autenticar com sucesso via saslauthd sem a permissão especificada no diretório saslauthd e seu conteúdo.

Para binários do MongoDB 4.2 Enterprise vinculados ao libldap (como ao executar no RHEL), o acesso ao libldap é sincronizado, incorrendo em alguns custos de desempenho/latência.

Para binários do MongoDB 4.2 Enterprise vinculados ao libldap_r, não há alteração no comportamento de versões anteriores do MongoDB.

O gerenciamento de usuários exige o gerenciamento de usuários no servidor LDAP e no servidor MongoDB. Para cada usuário autenticado via LDAP, o MongoDB requer um usuário no banco de dados $external cujo nome corresponda exatamente ao nome de usuário da autenticação. Alterações em um usuário no servidor LDAP podem exigir alterações no usuário MongoDB $external correspondente.

Para usar Client Sessions e Causal Consistency Guarantees com usuários de autenticação $external (usuários Kerberos, LDAP ou x.509), os nomes de usuário não podem ter mais de 10k bytes.

Exemplo

Um usuário autentica como sam@dba.example.com. O servidor MongoDB se liga ao servidor LDAP e autentica o usuário, respeitando qualquer username transformations. Na autenticação bem-sucedida, o servidor MongoDB então verifica o banco de dados do $external para um usuário sam@dba.example.com e concede ao usuário autenticado os papéis e privilégios associados a este usuário.

Para gerenciar usuários no servidor MongoDB, você deve se autenticar como um usuário LDAP cujo usuário MongoDB $external correspondente tenha privilégios administrativos de usuário no banco de dados $external, como os fornecidos pelo userAdmin.

Importante

Se nenhum usuário $external tiver privilégios administrativos de usuário no banco de dados $external, não será possível executar o gerenciamento de usuários para autenticação LDAP. Esse cenário pode ocorrer se você configurar usuários antes de ativar a autenticação LDAP, mas não criar os administradores de usuários apropriados.

Se houver usuários existentes que não estejam no banco de dados $external, você deverá atender aos seguintes requisitos para cada usuário a fim de garantir o acesso contínuo:

  • O usuário tem um objeto de usuário correspondente no servidor LDAP

  • O usuário existe no banco de dados do $external com privilégios e papéis equivalentes

Se quiser continuar permitindo o acesso de usuários que não estejam no banco de dados $external, será necessário configurar setParameter authenticationMechanisms para incluir SCRAM-SHA-1 e/ou SCRAM-SHA-256, conforme apropriado. Os usuários devem então especificar --authenticationMechanism SCRAM-SHA-1 ou SCRAM-SHA-256 ao autenticar.

Para conjuntos de réplicas, configure a autenticação LDAP em membros secundários e árbitros antes de configurar o principal. Isso também se aplica a conjuntos de réplicas de shards ou conjuntos de réplicas de servidores de configuração. Configure um membro do conjunto de réplicas por vez para manter a maioria dos membros para disponibilidade de gravação.

Em clusters sharded, é necessário configurar a autenticação LDAP nos servidores de configuração e em cada mongos para usuários no nível do cluster. Opcionalmente, é possível configurar a autorização LDAP em cada shard para usuários locais do shard.

O processo de autenticação LDAP utilizando bibliotecas de sistemas operacionais é resumida abaixo:

  1. Um cliente se autentica no MongoDB, fornecendo as credenciais do usuário.

  2. Se o nome de usuário exigir o mapeamento para um DN LDAP antes da vinculação ao servidor LDAP, o MongoDB poderá aplicar transformações com base na configuração desecurity.ldap.userToDNMapping configurada.

  3. O MongoDB se vincula a um servidor LDAP especificado em security.ldap.servers usando o nome de usuário fornecido ou, se uma transformação foi aplicada, o nome de usuário transformado.

    O MongoDB usa vinculação simples por padrão, mas também pode usar sasl vinculação se configurado em security.ldap.bind.method e security.ldap.bind.saslMechanisms.

    Se uma transformação exigir query do servidor LDAP ou se o servidor LDAP não permitir vínculos anônimos, o MongoDB utilizará o nome de usuário e senha especificados no security.ldap.bind.queryUser e security.ldap.bind.queryPassword para vincular ao servidor LDAP antes de tentar autenticar as credenciais de usuário fornecidas.

  4. O servidor LDAP retorna o resultado da tentativa de vinculação ao MongoDB. Em caso de sucesso, o MongoDB tenta autorizar o usuário.

  5. O servidor MongoDB tenta mapear o nome de usuário para um usuário no banco de dados do $external, atribuindo ao usuário quaisquer papéis ou privilégios associados a um usuário correspondente. Se o MongoDB não conseguir encontrar um usuário correspondente, a autenticação falhará.

  6. O cliente pode executar as ações para as quais o MongoDB concedeu roles ou privilégios ao usuário autenticado.

Para usar o LDAP para autenticação por meio de bibliotecas do sistema operacional, especifique as seguintes configurações como parte do arquivo de configuração mongod ou mongos:

Opção
Descrição
Obrigatório

Lista separada por vírgulas de servidores LDAP entre aspas no formato host[:port] .

Você pode prefixar servidores LDAP com srv: e srv_raw:.

Se sua connection string especificar "srv:<DNS_NAME>", mongod verificará se "_ldap._tcp.gc._msdcs.<DNS_NAME>" existe para que o SRV seja compatível com o Active Directory. Se não encontrado, mongod verifica se "_ldap._tcp.<DNS_NAME>" existe para SRV. Se não for possível encontrar um registro SRV, mongod avisa para usar "srv_raw:<DNS_NAME>" no lugar.

Se a connection string especificar "srv_raw:<DNS_NAME>", mongod executará uma pesquisa de registro SRV para "<DNS NAME>".

sim

Utilizado para especificar o método que o mongod ou mongos utiliza para autenticar ou vincular ao servidor LDAP. Especifique sasl para utilizar um dos protocolos SASL definidos no security.ldap.bind.saslMechanisms.

Padrão é simple.

NÃO, a menos que esteja usando o sasl para vincular ao servidor LDAP.

Usado para especificar os mecanismos SASL que mongod ou mongos podem usar ao autenticar ou vincular ao servidor LDAP. O MongoDB e o servidor LDAP devem concordar com pelo menos um mecanismo SASL.

Padrão é DIGEST-MD5.

NÃO, a menos que você defina method como sasl e precise de mecanismos SASL diferentes ou adicionais.

A entidade LDAP, identificada por seu nome distinto (DN) ou nome SASL, com o qual o servidor MongoDB autentica, ou se liga, ao se conectar a um servidor LDAP.

Use com queryPassword.

O usuário especificado deve ter os privilégios apropriados para executar queries no servidor LDAP.

NÃO, a menos que especifique uma query como parte de uma transformação do userToDNMapping ou se as configurações de segurança do servidor LDAP não permitirem vínculos anônimos.
A senha usada para autenticar em um servidor LDAP ao usar queryUser.
NÃO, a menos que especifique queryUser.
As implantações do Windows MongoDB podem utilizar as credenciais do sistema operacional em vez do queryUser e queryPassword para autenticar ou vincular como ao conectar ao servidor LDAP.
NÃO, a menos que substitua queryUser e queryPassword.

Os clientes podem autenticar utilizando um nome de usuário cujo formato é incompatível com o formato esperado pelo bind method configurado. Por exemplo, a vinculação do simple pode exigir uma DN LDAP completa, enquanto o nome de usuário usado para autenticar no MongoDB pode ser um endereço de e-mail.

userToDNMapping permite que o MongoDB transforme os nomes de usuário recebidos em um formato compatível com seu esquema LDAP. O MongoDB permite transformações usando um modelo de substituição ou um modelo de query LDAP.

Se especificar uma transformação do userToDNMapping que utiliza consultas LDAP como parte da transformação, você também deverá especificar um queryUser com o nível apropriado de permissões para o servidor LDAP

NÃO, exceto se o cliente se autenticar com nomes de usuário que necessitem de transformação.

Aviso

O MongoDB Enterprise para Windows não suporta ligação via saslauthd.

  • Os servidores Linux MongoDB suportam ligação a um servidor LDAP através do daemon saslauthd.

  • Utilize conexões seguras criptografadas ou confiáveis entre clientes e o servidor, como também, entre o saslauthd e o servidor LDAP. O servidor LDAP utiliza o mecanismo SASL PLAIN, enviando e recebendo dados em texto sem formatação. Você deve usar apenas um canal confiável, como uma VPN, uma conexão criptografada com TLS/SSL ou uma rede cabeada confiável.

Para configurar o servidor MongoDB para vincular ao servidor LDAP utilizando via saslauthd, inicie o mongod utilizando as seguintes opções de linha de comando ou as seguintes configurações de arquivo de configuração:

É necessário criar ou atualizar o arquivo saslauthd.conf com os parâmetros apropriados para o seu servidor LDAP. Documentar saslauthd.conf está fora do escopo desta documentação.

Importante

O diretório pai do arquivo de soquete de domínio Unix do saslauthd especificado para security.sasl.saslauthdSocketPath ou --setParameter saslauthdPath deve conceder permissões de leitura e execução (r-x) para:

  • O usuário iniciando o mongod ou mongos, ou

  • Um grupo ao qual esse usuário pertence.

O mongod ou mongos não pode autenticar com sucesso via saslauthd sem a permissão especificada no diretório saslauthd e seu conteúdo.

Os seguintes tutoriais fornecem informações básicas sobre configurar o saslauthd.conf para trabalhar com dois serviços LDAP populares:

Consulte a documentação do saslauthd, e do seu serviço LDAP específico para obter conselhos.

Para autenticar em um servidor MongoDB via autenticação LDAP, utilize o db.auth() no banco de dados do $external com os seguintes parâmetros:

Opção
Descrição
username
O nome de usuário para autenticar como.
password
A senha necessária para autenticar.
mechanism
Defina como PLAIN.
← Configure o MongoDB com autenticação Kerberos e autorização do Active Directory