Autenticar e autorizar usuários usando o Active Directory autogerenciado com LDAP nativo
Nesta página
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 fornece suporte por meio de bibliotecas LDAP da plataforma para solicitações de autenticação e autorização proxy para um serviço LDAP (Lightweight Directory Access Protocol) especificado, como o Active Directory (AD).
Este tutorial descreve como configurar o MongoDB para executar autenticação e autorização por meio de um servidor Active Directory (AD) por meio das bibliotecas de plataformas.
Observação
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.
Pré-requisitos
Importante
Familiarize-se completamente com os seguintes assuntos antes de prosseguir:
Uma descrição completa do AD está além do escopo deste tutorial. Este tutorial pressupõe conhecimento prévio do AD.
O MongoDB suporta o uso de mecanismos SASL para ligação entre o servidor MongoDB e o AD. Uma descrição completa do SASL, mecanismos SASL ou os requisitos específicos de configuração do AD para um determinado mecanismo SASL estão além do escopo deste tutorial. Este tutorial pressupõe o conhecimento prévio do SASL e seu assunto relacionado.
Configurar autenticação de membro interno
Você deve configurar a autenticação do nó interno antes de poder configurar a autenticação ou autorização LDAP para um cluster.
Considerações
Este tutorial explica como configurar o MongoDB para autenticação e autorização AD .
Para executar esse procedimento em seu próprio MongoDB Server, você deve modificar os procedimentos fornecidos em relação à sua infraestrutura específica, especialmente as configurações do Active Directory, a construção de query do AD ou o gerenciamento de usuários.
Segurança da camada de transporte
Por padrão, o MongoDB cria uma conexão TLS/SSL ao se vincular ao servidor AD. Isso requer a configuração do host do servidor MongoDB para ter acesso aos certificados de Autoridade de Certificação (CA) do servidor AD.
Este tutorial fornece instruções para as configurações de host necessárias.
Este tutorial pressupõe que você tenha acesso aos certificados CA do servidor AD e possa criar uma cópia dos certificados no servidor MongoDB.
Nomes de Usuário
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 de esquema do Active Directory
Este tutorial usa os seguintes exemplo de objetos do AD como base para as queries, configurações e saída fornecidas. Cada objeto mostra apenas um subconjunto dos possíveis atributos.
Objetos de usuário
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
Objetos de grupo
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
Credenciais do Active Directory
Este tutorial utiliza um nome de usuário e senha para executar queries no servidor AD . As credenciais fornecidas devem ter privilégios suficientes no servidor AD para suportar queries relacionadas a security.ldap.userToDNMapping
ou security.ldap.authz.queryTemplate
.
Conjuntos de réplicas
A autorização LDAP do MongoDB requer que cada mongod
no conjunto de réplicas esteja ativado pelo menos no MongoDB 3.4.0 ou mais tarde.
Clusters fragmentados
A autorização LDAP do MongoDB exige que todos os mongod
e mongos
do cluster fragmentado sejam pelo menos do MongoDB 3.4.0 ou posterior.
Procedimento
Configurar TLS/SSL para o servidor que executa o MongoDB
Para se conectar ao servidor AD (AD) via TLS/SSL, o mongod
ou mongos
exige acesso ao certificado da Autoridade de Certificação (CA) do servidor AD .
No Linux, especifique os certificados CA do servidor AD por meio da opção TLS_CACERT
ou TLS_CACERTDIR
no arquivo ldap.conf
.
O gerenciador de pacotes da sua plataforma cria o arquivo ldap.conf
ao instalar a dependência libldap
do MongoDB Enterprise. Para obter a documentação completa do arquivo de configuração ou das opções indicadas, consulte ldap.conf.
No Microsoft Windows, carregue os certificados de Autoridade de Certificação (CA) do servidor AD com a ferramenta de gerenciamento de credenciais da plataforma. A ferramenta exata de gerenciamento de credenciais depende da versão do Windows . Para usar a ferramenta, consulte a documentação referente à sua versão do Windows.
Se mongod
ou mongos
não puderem acessar os arquivos AD CA, não poderão criar conexões TLS/SSL com o servidor Active Directory.
Opcional: defina security.ldap.transportSecurity
como none
para desabilitar TLS/SSL.
Aviso
Definir transportSecurity
como none
transmite informações de texto simples, inclusive credenciais de usuário, entre o MongoDB e o servidor AD.
Conecte-se ao servidor MongoDB.
Conecte-se ao servidor do MongoDB usando as opções mongosh
--host
e --port
.
mongosh --host <hostname> --port <port>
Se seu servidor do MongoDB atualmente forçar autenticação, você deverá autenticar no banco de dados do admin
como um usuário com privilégio de gerenciamento de funções, como as fornecidas por userAdmin
ou userAdminAnyDatabase
. Inclua o devido --authenticationMechanism
para o mecanismo de autenticação configurado do servidor do MongoDB.
mongosh --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"
Criar função administrativa de usuário.
Para gerenciar usuários MongoDB utilizando AD, você precisa criar pelo menos uma função no banco de banco de dados do admin
que pode criar e gerenciar funções, como as fornecidas pelo userAdmin
ou userAdminAnyDatabase
.
O nome da função deve corresponder exatamente ao Nome Distinto de um grupo do AD. O grupo deve ter pelo menos um usuário do AD como membro.
Considerando os grupos disponíveis do Active Directory, a seguinte operação:
Cria um papel nomeado para o grupo AD
CN=dba,CN=Users,DC=example,DC=com
eAtribui a ele a função
userAdminAnyDatabase
no banco de dadosadmin
.
var admin = db.getSiblingDB("admin") admin.createRole( { role: "CN=dba,CN=Users,DC=example,DC=com", privileges: [], roles: [ "userAdminAnyDatabase" ] } )
Outra opção é conceder a função userAdmin
para cada banco de dados no qual o usuário deva ter privilégios administrativos de usuário. Essas funções fornecem os privilégios necessários para a criação e o gerenciamento de funções.
Importante
Considere aplicar o privilégio mínimo ao configurar funções do MongoDB, grupos do AD ou associação a grupos.
Crie um arquivo de configuração do MongoDB.
Um arquivo de configuração do MongoDB é um arquivo YAML de texto simples com a extensão de arquivo .conf
.
Se você estiver atualizando uma implantação do MongoDB, copie o arquivo de configuração atual e trabalhe a partir dessa cópia.
(Somente Linux) Se essa for uma nova implantação e você tiver usado o gerenciador de pacotes da sua plataforma para instalar o MongoDB Enterprise, a instalação conterá o arquivo de configuração padrão
/etc/mongod.conf
. Use esse arquivo de configuração padrão ou faça uma cópia desse arquivo para trabalhar.Se esse arquivo não existir, crie um arquivo vazio com a extensão
.conf
e trabalhe a partir desse novo arquivo de configuração.
Configure o MongoDB para se conectar ao Active Directory.
No arquivo de configuração do MongoDB, defina security.ldap.servers
como o host e a porta do servidor AD. Se sua infraestrutura do AD incluir vários servidores do AD para fins de replicação, especifique o host e a porta dos servidores como uma lista delimitada por vírgulas até security.ldap.servers
.
Você também deve habilitar a autenticação LDAP configurando security.authorization
para enabled
e setParameter
authenticationMechanisms
para PLAIN
Exemplo
Para se conectar a um servidor AD localizado em activedirectory.example.net
, inclua o seguinte no arquivo de configuração:
security: authorization: "enabled" ldap: servers: "activedirectory.example.net" setParameter: authenticationMechanisms: 'PLAIN'
O MongoDB deve se vincular ao servidor AD para executar queries. Por padrão, o MongoDB usa o mecanismo de autenticação simples para se vincular ao servidor AD .
Como alternativa, você pode definir as seguintes configurações no arquivo de configuração para vincular-se ao servidor AD usando SASL
:
Defina
security.ldap.bind.method
comosasl
security.ldap.bind.saslMechanisms
, especificando uma string de mecanismos SASL separados por vírgula que o servidor AD suporta.
Este tutorial utiliza o mecanismo de autenticação LDAP simple
padrão.
Configure o modelo de consulta LDAP para autorização.
No arquivo de configuração do MongoDB, defina security.ldap.authz.queryTemplate
para um modelo de URL de query LDAP formatado RFC4516.
No modelo, você pode usar:
O placeholder
{USER}
substituirá o nome de usuário autenticado na URL de query LDAP.{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.
Observação
Uma descrição completa da RFC4515, RFC4516, ou as queries do AD estão fora do escopo deste tutorial. O queryTemplate
fornecido neste tutorial é apenas um exemplo e pode não ser aplicável à sua implantação específica do AD .
Exemplo
O modelo de consulta a seguir retorna todos os grupos que listam {USER}
como membro, seguindo associações de grupo recursivas. Essa consulta LDAP pressupõe que os objetos de grupo rastreiam a associação do usuário armazenando o DN (Nome Distinto) completo do usuário usando o atributo member
. A consulta inclui a regra de correspondência específica do AD OID 1.2.840.113556.1.4.1941
para LDAP_MATCHING_RULE_IN_CHAIN. Esta regra de correspondência é uma extensão específica do AD para filtros de pesquisa LDAP.
Aviso
Se a mata do AD contiver um grande número de grupos, o filtro member:1.2.840.113556.1.4.1941
recursivo poderá levar a uma degradação significativa do desempenho.
security: ldap: authz: queryTemplate: "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"
Utilizando a consulta, o MongoDB substitui o {USER}
pelo nome de usuário autenticado para consultar o servidor LDAP.
Por exemplo, um usuário autentica como CN=sam,CN=Users,DC=dba,DC=example,DC=com
. O MongoDB cria uma query LDAP com base no queryTemplate
, substituindo o token {USER}
pelo nome de usuário autenticado/transformado. O servidor do Active Directory executa uma pesquisa de grupo recursiva para qualquer grupo que liste direta ou transitivamente o usuário como membro. Com base nos grupos do Active Directory, o servidor AD retorna os seguintes 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
O MongoDB mapeia cada DN de grupo retornado para uma função no banco de dados admin
. Para cada DN de grupo mapeado, se houver uma função existente no banco de dados admin
cujo nome corresponda exatamente ao DN, o MongoDB concederá ao usuário as funções e privilégios atribuídos a essa função.
A regra de correspondência LDAP_MATCHING_RULE_IN_CHAIN
exige o fornecedor do nome diferenciado completo do usuário de autenticação. Se os usuários se autenticarem usando um formato de nome de usuário diferente, como user
principal name
, você deverá transformar os nomes de usuário recebidos em DNs usando security.ldap.userToDNMapping
.
Opcional: transformar os nomes de usuário recebidos para autenticação via Active Directory,
Se seus usuários se autenticarem com um nome diferenciado que não é um LDAP completo, talvez seja necessário transformar o nome diferenciado para suportar a autenticação ou autorização LDAP. O MongoDB usa o nome de usuário transformado para autenticação e autorização.
No arquivo de configuração MongoDB , configure userToDNMapping
para transformar o nome de usuário fornecido do usuário de autenticação em um DN do AD para suportar o queryTemplate
.
Exemplo
Dado o queryTemplate
configurado, os usuários devem autenticar com seu nome diferenciado LDAP completo. Se, em vez disso, os usuários se autenticarem usando o userPrincipalName
, uma transformação deverá ser aplicada para converter o nome de usuário fornecido em um nome diferenciado LDAP completo.
A seguinte configuração userToDNMapping
utiliza o filtro de expressão regular do match
para captar o nome de usuário fornecido. O MongoDB insere o nome de usuário captado no modelo de query ldapQuery
antes de executar a query.
security: ldap: userToDNMapping: '[ { match : "(.+)", ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})" } ]'
O servidor Active Directory retorna o DN LDAP completo associado ao objeto de usuário com um userPrincipalName
correspondente. O MongoDB pode então usar esse nome de usuário transformado para autenticação e autorização.
Você deve modificar a configuração de amostra fornecida para corresponder à sua implantação. Por exemplo, o DN base
ldapQuery
deve corresponder ao DN base que contém suas entidades de usuário. Outras modificações podem ser necessárias para dar suporte à implantação do AD.
Exemplo
Um usuário se autentica como alice@ENGINEERING.EXAMPLE.COM
. O MongoDB primeiro aplica quaisquer transformações especificadas em userToDNMapping
. Com base na configuração fornecida, o MongoDB capta o nome de usuário no estágio match
e executa uma consulta LDAP:
DC=example,DC=com??sub?(userPrincipalName=alice@ENGINEERING.EXAMPLE.COM)
Com base nos usuários configurados do Active Directory, o servidor AD deve retornar CN=alice,CN=Users,DC=engineering,DC=example,DC=com
.
Em seguida, o MongoDB executa a consulta LDAP configurada em queryTemplate
, substituindo o token {USER}
pelo nome de usuário transformado CN=alice,CN=Users,DC=engineering,DC=example,DC=com
.
Importante
Se você usar o parâmetro substitution
do
userToDNMapping
para transformar o nome do grupo, o resultado da substituição deverá ser uma string RFC4514 escapada.
Configurar credenciais de query.
O MongoDB requer credenciais para realizar consultas no servidor AD.
Defina as seguintes configurações no arquivo de configuração:
security.ldap.bind.queryUser
, especificando o usuário do Active Directory, omongod
oumongos
se vincula como para executar query no servidor AD .security.ldap.bind.queryPassword
, especificando a senha para oqueryUser
especificado.
security: ldap: bind: queryUser: "mongodbadmin@dba.example.com" queryPassword: "secret123"
Nos servidores Windows MongoDB , você pode definir security.ldap.bind.useOSDefaults
como true
para usar as credenciais do usuário do sistema operacional em vez de queryUser
e queryPassword
.
O queryUser
deve ter permissão para executar todas as consultas LDAP em nome do MongoDB.
Opcional: adicione definições de configuração adicionais.
Adicione quaisquer opções de configuração adicionais necessárias para o seu sistema. Por exemplo, você pode especificar o storage.dbPath
desejado ou alterar o número net.port
padrão.
mongod
e mongos
são vinculados ao localhost por padrão. Se os membros do seu sistema forem executados em hosts diferentes, ou se você desejar que clientes remotos se conectem ao seu sistema, especifique a configuração net.bindIp
.
Inicie o servidor MongoDB com autenticação e autorização do Active Directory.
Inicie o servidor do MongoDB com a opção --config
, especificando o caminho para o arquivo de configuração criado durante esse procedimento. Se o servidor do MongoDB estiver em execução no momento, faça as devidas preparações para interromper o servidor.
mongod --config <path-to-config-file>
As implantações do Windows MongoDB devem usar mongod.exe
em vez de mongod
.
Conecte-se ao servidor MongoDB.
Conecte-se ao servidor do MongoDB, autenticando-se como um usuário cuja associação de grupo direta ou transitiva corresponda a uma função do MongoDB no banco de dados admin
com userAdmin
, userAdminAnyDatabase
ou uma função personalizada com privilégio equivalentes.
Com o objetivo de utilizar o mongosh
para autenticar no servidor do MongoDB, configure as seguintes opções:
--host
pelo nome do host do servidor MongoDB--port
com a porta do servidor MongoDB--username
para o nome de usuário do usuário--password
para a senha do usuário--authenticationMechanism
para'PLAIN'
--authenticationDatabase
para'$external'
Exemplo
Anteriormente neste procedimento, você configurou a função dn:CN=dba,CN=Users,DC=example,DC=com
no banco de dados admin
com as permissões necessárias. Esta função corresponde a um grupo AD . Com base nos usuários do AD configurados, você pode se autenticar como o usuário sam@dba.example.com
e receber as permissões necessárias.
mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanism 'PLAIN' --authenticationDatabase '$external' --host <hostname> --port <port>
Se você não especificar a senha para a opção de linha de comando -p
, o mongosh
solicitará a senha.
As implantações do MongoDB no Windows devem usar mongo.exe
em vez de mongosh
.
Considerando os usuários do Active Directory configurados, o usuário se autentica com sucesso e recebe as devidas permissões.
Observação
Se você quiser se autenticar como um usuário existente não$external
, defina --authenticationMechanism
como um mecanismo de autenticação SCRAM (por exemplo, SCRAM-SHA-1
ou SCRAM-SHA-256
, conforme apropriado). Isso requer que o setParameter
do servidor MongoDB authenticationMechanisms
inclua SCRAM-SHA-1
e/ou SCRAM-SHA-256
.
Crie roles para mapear grupos AD retornados.
Para cada grupo no servidor AD que você deseja usar para autorização MongoDB , você deve criar uma função correspondente no banco de banco de dados admin
do servidor MongoDB .
Exemplo
A operação a seguir cria uma função nomeada após o grupo AD DN CN=PrimaryApplication,CN=Users,DC=example,DC=com
, atribuindo funções e privilégios apropriados a esse grupo:
db.getSiblingDB("admin").createRole( { role: "CN=PrimaryApplication,CN=Users,DC=example,DC=com", privileges: [], roles: [ { role: "readWrite", db: "PrimaryApplication" } ] } )
Considerando os grupos configurados do Active Directory, o MongoDB permite que um usuário se autentique como a função sam@DBA.EXAMPLE.COM
ou alice@ENGINEERING.EXAMPLE.COM
readWrite
no banco de dados PrimaryApplication
.
Observação
Para funções gerenciadas no banco de dados admin
, você deve ser autenticado como um usuário com userAdmin
no admin
, userAdminAnyDatabase
ou uma função personalizada com privilégio equivalentes.
Transição de usuários existentes do $external
para o servidor ActiveDirectory
Se atualizar uma instalação existente com usuários configurados no banco de dados do $external
, você deverá atender aos seguintes requisitos para cada usuário para garantir o acesso após configurar o MongoDB para autenticação e autorização do AD :
O usuário tem um objeto de usuário correspondente no servidor AD .
O usuário tem associação nos grupos apropriados no servidor AD .
O MongoDB contém as funções no banco de dados
admin
nomeadas para os grupos AD do usuário, de forma que o usuário autorizado mantenha seus privilégios.
Exemplo
O seguinte usuário existe no banco de dados $external
:
{ user : "joe@ANALYTICS.EXAMPLE.COM", roles: [ { role : "read", db : "web_analytics" }, { role : "read", db : "PrimaryApplication" } ] }
Supondo que o usuário pertença ao grupo CN=marketing,CN=Users,DC=example,DC=com
do AD, a operação a seguir cria uma função correspondente com os privilégios apropriados:
db.getSiblingDB("admin").createRole( { role: "CN=marketing,CN=Users,DC=example,DC=com", privileges: [], roles: [ { role: "read", db: "web_analytics" } { role: "read", db: "PrimaryApplication" } ] } )
Com base no queryTemplate
configurado, o MongoDB autoriza qualquer usuário que tenha associação direta ou transitiva no grupo CN=marketing,CN=Users,DC=example,DC=com
a executar operações read
no banco de dados web_analytics
e PrimaryApplication
.
Importante
Ao configurar uma função para um grupo do AD correspondente, lembre-se de que todos os usuários com associação a esse grupo podem receber as funções e privilégios atribuídos. Considere aplicar o princípio do menor privilégio ao configurar funções do MongoDB, grupos doAD ou associação a grupos.
Se você quiser continuar permitindo que usuários em reconhecimento de data center não$external
acessem o MongoDB, inclua o mecanismo de autenticação SCRAM (por exemplo SCRAM-SHA-1
e/ou SCRAM-SHA-256
) na opção de configuração setParameter
authenticationMechanisms
. Por exemplo:
setParameter: authenticationMechanisms: "PLAIN,SCRAM-SHA-1,SCRAM-SHA-256"
Como alternativa, faça a transição de usuários não$external
para o AD seguindo o procedimento acima.
Esse procedimento produz o seguinte arquivo de configuração:
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"
A configuração de amostra fornecida requer modificação para corresponder ao esquema, à estrutura de diretórios e à configuração do Active Directory. Você também pode precisar de opções adicionais de arquivo de configuração para sua implantação.
Para obter mais informações sobre como configurar funções e privilégios, consulte: