Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Sistemas autogerenciados
/
Segurança
/
Controle de acesso baseado em funções

Autorização LDAP em implantações autogerenciadas

Nesta página

  • Considerações
  • Configuração
  • Tutorials
  • Conectando a um servidor MongoDB usando a autorização LDAP
  • Funções do MongoDB para autorização LDAP

Observação

A partir do MongoDB 8.0, A autenticação e autorização LDAP estão obsoletas. O LDAP está disponível e continuará a operar sem alterações durante a vida útil do MongoDB 8. O LDAP será removido em uma futura versão principal.

Para obter detalhes, consulte Descontinuação do LDAP.

O MongoDB Enterprise oferece suporte à query de um servidor LDAP para os grupos LDAP aos quais o usuário autenticado pertence. O MongoDB mapeia os nomes diferenciados (DN) de cada grupo retornado para funções no banco de dados admin. O MongoDB autoriza o usuário baseado nas funções mapeadas e seus privilégios associados. Consulte Autorização LDAP para obter mais informações.

O processo de Autorização LDAP é resumido abaixo:

  1. Um cliente se conecta ao MongoDB e realiza autenticação com qualquer mecanismo de autenticação que suporte autenticação externa.

    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.

  2. O MongoDB se liga ao servidor LDAP especificado com security.ldap.servers usando as credenciais especificadas com security.ldap.bind.queryUser e security.ldap.bind.queryPassword.

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

  3. O MongoDB constrói uma consulta LDAP usando security.ldap.authz.queryTemplate e consulta o servidor LDAP para obter a participação no grupo do usuário autenticado.

    O MongoDB pode usar a opção security.ldap.userToDNMapping para transformar o nome de usuário para dar suporte ao modelo de consulta.

  4. O servidor LDAP avalia a query e retorna a lista de grupos aos quais o usuário autenticado pertence.

  5. O MongoDB autoriza o usuário a executar ações no servidor mapeando o nome diferenciado (DN) de cada grupo retornado em uma função no banco de dados admin. Se o DN do grupo retornado corresponder exatamente ao nome de uma função existente no banco de dados admin, o MongoDB concederá ao usuário as funções e os privilégios atribuídos a essa função. Consulte Funções do MongoDB para autorização LDAP para obter mais informações.

  6. O cliente pode executar ações no MongoDB Server que requerem funções ou privilégios concedidos ao usuário autenticado.

  7. Em um intervalo definido por ldapUserCacheInvalidationInterval, o MongoDB libera o cache $external . Antes de executar operações subsequentes realizadas por usuários autorizados externamente, o MongoDB readquire sua associação ao grupo do servidor LDAP.

Considerações

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 autorizaçã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 autorização LDAP para a implantação MongoDB.

Mecanismo de autenticação compatível

O MongoDB suporta autorização LDAP com os seguintes métodos de autenticação:

Com esta configuração, o MongoDB usa a autorização LDAP, X.509 ou Kerberos para autenticar conexões de cliente.

Pool de Conexões

Ao se conectar ao servidor LDAP para autenticação/autorização, o MongoDB, por padrão:

  • Usa pool de conexões se executado:

    • no Windows ou

    • no Linux, onde os binários do MongoDB Enterprise estão vinculados ao 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.

libldap e a libldap_r

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.

Gerenciamento de usuários

Com a autorização LDAP, a criação e o gerenciamento de usuários ocorrem no servidor LDAP. O MongoDB requer a criação de funções no banco de dados admin , com o nome de cada função correspondendo exatamente a um Nome Distinto (DN) do grupo LDAP. Isso contrasta com a autorização managed do MongoDB, que requer a criação de usuários no banco de dados $external.

Para gerenciar funções no servidor MongoDB, autentique-se como um usuário cuja associação de grupo corresponde a uma função de banco de dados admin com privilégios de administração de função, como os fornecidos pelo userAdmin. Crie ou atualize funções correspondentes a DNs de grupos LDAP, de modo que os usuários com associação a esse grupo recebam as funções e os privilégios adequados.

Por exemplo, um grupo LDAP para administradores do banco de dados pode ter uma função com privilégios e papéis administrativos. Um grupo LDAP para usuários de marketing ou análise pode ter uma função com apenas privilégios de leitura em determinados bancos de dados.

Importante

Ao configurar um papel para um Grupo LDAP correspondente, lembre-se que todos os usuários com associação neste grupo podem receber os privilégios e papéis configurados. Considere a aplicação do princípio do mínimo privilégio ao configurar funções do MongoDB, grupos LDAP ou associação a grupos.

Se nenhuma função com privilégios de administração de função existir E nenhum usuário não$external com esses privilégios existir, você efetivamente não poderá executar o gerenciamento de usuários, pois nenhuma função nova ou existente poderá ser alterada para refletir adições ou alterações em grupos ou associação a grupos no servidor LDAP.

Para corrigir um cenário em que você não pode gerenciar funções no servidor MongoDB, execute o seguinte procedimento:

  1. Reinicie o servidor MongoDB sem autenticação e autorização LDAP

  2. Crie uma função no banco de dados do admin cujo nome corresponde ao grupo de LDAP Distinguished Name apropriado. Ao escolher um grupo de ND, considere qual grupo é mais apropriado para a administração do banco de dados.

  3. Reinicie o servidor MongoDB com autenticação e autorização LDAP

  4. Autenticar como um usuário com associação no grupo correspondente ao papel administrativo criado.

Usuários existentes

Um servidor MongoDB utilizando LDAP para autorização torna quaisquer usuários existentes no banco de dados do $external inacessível. Se houver usuários existentes no banco de dados do $external , você deverá atender os seguintes requisitos para cada usuário no banco de dados do $external para garantir acesso contínuo:

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

  • O objeto de usuário tem associação nos grupos LDAP apropriados

  • O MongoDB tem funções no banco de dados admin nomeadas para os grupos LDAP do usuário, de modo que as funções e os privilégios concedidos são idênticos aos concedidos ao usuário não$external.

Se você quiser continuar permitindo o acesso de usuários que não estão no banco de dados $external, verifique se o parâmetro authenticationMechanisms inclui SCRAM-SHA-1 e/ou SCRAM-SHA-256 conforme apropriado. Como alternativa, aplique os requisitos listados acima para a transição desses usuários para a autorização LDAP.

Conjuntos de réplicas

Para conjuntos de réplicas, configure primeiro a autorização LDAP nos membros secundários e árbitros , antes de configurar o primário. Isso também se aplica a conjuntos de réplicas de fragmentos ou conjuntos de réplicas de servidor de configuração. Configure um membro do conjunto de réplicas por vez para manter a maioria dos membros para disponibilidade de gravação.

Clusters fragmentados

Em clusters fragmentados, você deve configurar a autorização LDAP nos servidores de configuração para usuários em nível de cluster. Opcionalmente, você pode configurar a autorização LDAP em cada fragmento para usuários locais do fragmento.

Configuração

Você deve definir as seguintes configurações para usar a Autorização LDAP:

Para usar o LDAP para autorizaçã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

Um RFC4515 e RFC4516 Modelo de URL de query formatado em LDAP executado pelo MongoDB para obter os grupos LDAP aos quais o usuário pertence. A query é relativa ao host ou hosts especificados no servers.

Você pode utilizar os seguintes tokens no modelo:

  • {USER}
    Substitui o nome de usuário autenticado ou o nome de usuáriotransformed na query LDAP.
  • {PROVIDED_USER}
    Substitui o nome de usuário fornecido, ou seja, antes da autenticação ou da transformação LDAP, na query LDAP.

Somente mongod suporta esse parâmetro. mongos segue essa configuração conforme configurada em seus servidores de configuração

sim

A identidade do servidor MongoDB se liga como ao conectar e executar operações e consultas em um servidor LDAP.

Use com queryPassword.

O usuário especificado deve ter os privilégios apropriados para suportar as consultas LDAP geradas a partir do queryTemplate configurado.

sim
A senha usada para vincular a um servidor LDAP ao utilizar o queryUser.
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ê configure method para sasl e precise de mecanismos SASL diferentes ou adicionais.
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.
Dependendo do seu queryTemplate, o nome de usuário do cliente autenticado pode exigir transformação para suportar o URL de consulta LDAP. userToDNMapping permite que o MongoDB transforme nomes de usuários recebidos.
NÃO, a menos que os nomes de usuário do cliente precisem ser transformados em DNs LDAP.

Após configurar a autorização LDAP, reinicie o mongod ou mongos. O servidor agora usa autorização LDAP com X.509, Kerberos ou LDAP para autenticar conexões de cliente.

Modelo de consulta LDAP

O MongoDB utiliza o security.ldap.authz.queryTemplate para criar um URL de query LDAP formatada RFC4516. No modelo, você pode usar:

  • {USER} espaço reservado para substituir o nome de usuário autenticado na URL de consulta do LDAP. Se o MongoDB transformou o username usando userToDNMapping, o MongoDB substitui o token {USER} pelo username transformado ao construir o query LDAP URL.

  • {PROVIDED_USER} espaço reservado para substituir o nome de usuário fornecido, ou seja, antes da autenticação ou transformação LDAP, na query LDAP.

Crie o modelo de query para recuperar os grupos do usuário.

Exemplo

O modelo de consulta seguinte retorna quaisquer grupos listados no atributo memberOf do objeto de usuário LDAP. Essa query pressupõe que o atributo memberOf exista - sua implantação específica do LDAP pode usar um atributo ou metodologia diferente para rastrear a associação ao grupo. Esta consulta também pressupõe que o usuário autentique usando seu DN LDAP completo como seu nome de usuário.

"{USER}?memberOf?base"

O URL de query LDAP deve estar em conformidade com o formato definido em RFC4516:

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

Considere a definição de cada componente, conforme citado no RFC4516:

O dn é um LDAP de Nome Diferenciado que usa o formato de string descrito na RFC4514. Identifica o objeto base da pesquisa LDAP ou o destino de uma operação que não seja de pesquisa.

A construção de attributes é utilizada para indicar quais atributos devem ser retornados da entrada ou entradas.

A construção de scope é utilizada para especificar o escopo da pesquisa para executar no servidor LDAP fornecido. Os escopos permitidos são "base" para uma procurar de objeto base, "um" para uma procurar de um nível ou "sub" para uma procurar de subárvore.

O filter é usado para especificar o filtro de pesquisa a ser aplicado às entradas dentro do escopo especificado durante a pesquisa. Tem o formato especificado em [RFC4515].

A construção de extensions fornece a URL LDAP com um mecanismo de extensibilidade, permitindo que os recursos da URL sejam estendidos no futuro.

Se a query incluir um attribute, o MongoDB assume que a query recupera um dos DNs dos quais essa entidade é membro.

Se a query não incluir um atributo, MongoDB assumirá que a query recupera todas as entidades das quais o usuário é membro.

O MongoDB ignora atualmente quaisquer extensões especificadas na query LDAP.

Importante

Uma descrição completa da construção de URL de query RFC4516 ou LDAP está fora de escopo para esta documentação.

Tutorials

Os tutoriais a seguir contêm procedimentos para se conectar a um servidor LDAP por meio das bibliotecas LDAP do sistema operacional:

Conectando a um servidor MongoDB usando a autorização LDAP

Ao usar o LDAP para fazer a autorização, os usuários que se conectam via mongosh devem:

Inclua o --host e o --port do servidor MongoDB, juntamente com quaisquer outras opções relevantes para sua implantação.

Por exemplo, a operação a seguir autentica em um servidor MongoDB em execução com autenticação e autorização LDAP:

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

Se você não especificar a senha para a opção de linha de comando --password, o mongosh solicitará a senha.

Importante

O argumento $external deve ser colocado entre aspas simples, e não entre aspas duplas, para evitar que o shell interprete $external como uma variável.

Funções do MongoDB para autorização LDAP

O MongoDB mapeia cada nome distinto (DN) de grupo retornado pelo LDAP query para uma função no banco de dados admin.

Se o MongoDB adquirir um grupo cujo DN corresponda exatamente ao nome de uma role existente, o MongoDB concederá ao usuário autenticado as roles e os privilégios associados a essa role. Se o MongoDB não puder mapear nenhum dos grupos retornados para uma role, o MongoDB não concederá privilégios ao usuário.

Observação

A autenticação LDAP e kerberos normalmente requer a criação de usuários no banco de dados $external. Se você também utilizar LDAP para autorização, você não precisará criar usuários no banco de dados do $external. Você somente precisa criar as roles apropriadas no banco de dados do admin. Os usuários ainda autenticam no banco de dados do $external.

Importante

Se você estiver usando LDAP para autorização e os DNs do grupo LDAP contiverem sequências de escape RFC4514, as funções criadas no banco de dados admin também deverão ter escape de acordo com RFC4514.

Exemplo

Um banco de dados tem as seguintes roles configuradas no banco de dados do 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" }
       ]
}

Após autenticar um usuário alice@dba.example.com no banco de dados do $external , o servidor MongoDB executa uma query derivada do query template configurado para recuperar os grupos que incluem o usuário autenticado como um membro. Neste exemplo, o servidor MongoDB recupera os seguintes DNs de grupo para o usuário:

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

O MongoDB mapeia estes DNs do grupo para roles no banco de dados do admin. O primeiro grupo DN corresponde ao primeiro role, e o MongoDB concede ao usuário autenticado seus roles e privilégios. O segundo grupo DN não corresponde a nenhum role no servidor, portanto, o MongoDB não concede permissões adicionais.

Um novo usuário bob@analytics.example.com autentica no banco de dados do $external. O servidor MongoDB repete o processo de query, usando o nome de usuário fornecido no modelo de query. Neste exemplo, o servidor MongoDB recupera os seguintes DNs de grupo para o usuário:

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

O MongoDB mapeia estes DNs do grupo para papéis no banco de dados do admin e concede ao usuário autenticado as roles e privilégios da segunda role.

Um novo usuário workstation@guest.example.com autentica no banco de dados do $external. O servidor MongoDB repete o processo de query, usando o nome de usuário fornecido no modelo de query. Neste exemplo, o servidor MongoDB recupera os seguintes DNs de grupo para o usuário:

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

O MongoDB mapeia o grupo para uma role no banco de dados admin e, como não existem funções correspondentes, não concede permissões adicionais ao usuário.

Voltar

Controle de acesso no nível da coleção

Próximo

Descontinuação do LDAP