Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Configure o MongoDB com autenticação Kerberos e autorização do Active Directory
Novidades na versão 3.4: OMongoDB Enterprise oferece suporte à query de um servidor LDAP para os grupos LDAP aos quais pertence um usuário autenticado. O MongoDB mapeia os nomes distintos (DN) LDAP de cada grupo retornado para roles no banco de dados admin
. O MongoDB autoriza o usuário baseado nos roles mapeados e seus privilégios associados. Consulte Autorização LDAP para obter mais informações.
O MongoDB Enterprise oferece suporte à autenticação usando um serviço Kerberos. O Kerberos é um protocolo de autenticação padrão do setor para grandes sistemas de cliente/servidor.
Este tutorial descreve como configurar o MongoDB para executar a autenticação por meio de um servidor Kerberos e a autorização por meio de um servidor Active Directory (AD) por meio das bibliotecas de plataforma.
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 de AD.
O MongoDB oferece suporte ao uso de mecanismos SASL para vinculação entre o MongoDB Server e o AD. Uma descrição completa do SASL, mecanismos do SASL ou os requisitos específicos de configuração do AD para um determinado mecanismo do SASL estão além do escopo deste tutorial. Este tutorial pressupõe conhecimento prévio do SASL e do assunto relacionado.
A instalação e a configuração de um sistema do Kerberos estão além do escopo deste documento. Este tutorial pressupõe que você tenha configurado uma entidade de serviço Kerberos para cada instância mongod
e mongos
em sua implantação do MongoDB e tenha um arquivo keytab válido para cada instância mongod
e mongos
.
Para conjuntos de réplicas e clusters fragmentados, verifique se sua configuração usa nomes de domínio totalmente qualificados (FQDN) em vez de endereços IP ou nomes de host não qualificados. Você deve usar o FQDN para GSSAPI para resolver corretamente os domínios Kerberos e permitir que você se conecte.
Para verificar se você está usando o MongoDB Enterprise, passe a opção de linha de comando --version
para mongod
ou mongos
:
mongod --version
Na saída deste comando, procure a string modules:
subscription
ou modules: enterprise
para confirmar que você está usando os binários MongoDB Enterprise.
Considerações
Este tutorial explica como configurar o MongoDB para autenticação Kerberos 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 Kerberos, 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 vincular ao servidor AD . Isso requer a configuração do host do MongoDB Server 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 de CA do servidor AD e possa criar uma cópia dos certificados no servidor MongoDB.
Exemplo de Esquema do Active Directory
Este tutorial usa os seguintes objeto de exemplo do AD como base para as query, 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 do 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 usa um nome de usuário e senha para realizar query no servidor AD . As credenciais fornecidas devem ter privilégios suficientes no servidor AD para suportar consultas 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 pelo menos no MongoDB 3.4.0 ou posterior.
Clusters fragmentados
A autorização LDAP do MongoDB requer que cada mongod
e mongos
no cluster fragmentado esteja em pelo menos MongoDB 3.4.0 ou posterior.
Procedimento
Configure 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 de 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 ldap.conf
arquivo durante a instalação da dependência do MongoDB libldap
Enterprise. Para obter a documentação completa sobre o arquivo de configuração ou as opções referenciadas, 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 da 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.
Opcionalmente, defina security.ldap.transportSecurity
como none
para desabilitar TLS/SSL.
Aviso
Definir transportSecurity
para none
transmite informações de texto simples, incluindo credenciais de usuário, entre MongoDB e o servidor AD .
(Somente Windows) Atribua um nome principal de serviço ao serviço MongoDB Windows.
Para servidores MongoDB em execução no sistema operacional Windows , você deve usar setspn.exe para atribuir o nome principal de serviço (SPN) à conta que executa o serviço MongoDB.
setspn.exe -S <service>/<fully qualified domain name> <service account name>
Exemplo
Por exemplo, se um mongod
for executado como um serviço denominado mongodb
em mongodbserver.example.com
com o nome da conta de serviço mongodb_dev@example.com
, o comando para atribuir o SPN será o seguinte:
setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com
Observação
O Windows Server 2003 não suporta setspn.exe -S
. Para obter a documentação completa sobre setspn.exe
, consulte setspn.exe.
(Somente Linux) Crie um arquivo keytab para o servidor MongoDB.
Para servidores MongoDB em execução na plataforma Linux, você deve garantir que o servidor tenha uma cópia do arquivo keytab específico para a instância do MongoDB em execução nesse servidor.
Você deve conceder ao usuário Linux que executa o serviço MongoDB permissões de leitura no arquivo keytab. Anote o caminho completo da localização do arquivo keytab.
Conecte-se ao servidor MongoDB.
Conecte ao servidor MongoDB utilizando o mongosh
utilizando as opções --host
e --port
.
mongosh --host <hostname> --port <port>
Se o seu servidor MongoDB atualmente impõe autenticação, você deve autenticar no banco de dados do admin
como um usuário com privilégios de gerenciamento de papel, como os fornecidos pelo userAdmin
ou userAdminAnyDatabase
. Inclua o --authenticationMechanism
apropriado para o mecanismo de autenticação configurado do servidor MongoDB.
mongosh --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"
Criar função administrativa do usuário.
Para managed usuários do MongoDB usando o AD, você precisa criar pelo menos um papel no reconhecimento de data center do admin
que pode criar e managed papéis, como os fornecidos pelo userAdmin
ou userAdminAnyDatabase
.
O nome da role deve corresponder exatamente ao nome diferenciado de um grupo do AD . O grupo deve ter pelo menos um usuário AD como membro.
Considerando os grupos do Active Directory disponíveis, a seguinte operação:
Cria um papel nomeado para o grupo AD
CN=dba,CN=Users,DC=example,DC=com
eAtribui a ele o role
userAdminAnyDatabase
no banco de dadosadmin
.
var admin = db.getSiblingDB("admin") admin.createRole( { role: "CN=dba,CN=Users,DC=example,DC=com", privileges: [], roles: [ "userAdminAnyDatabase" ] } )
Como alternativa, você pode conceder a função userAdmin
para cada banco de dados no qual o usuário deve 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 a aplicação do princípio do menor privilégio ao configurar roles do MongoDB, gruposdo 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 sem formatação com a extensão de arquivo .conf
.
Se você estiver atualizando um sistema MongoDB existente, copie o arquivo de configuração atual e trabalhe a partir dessa cópia.
(Somente Linux) Se esta for uma nova implantação e você usou o gerenciador de pacotes da sua plataforma para instalar o MongoDB Enterprise, a instalação incluirá 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 MongoDB, defina security.ldap.servers
para 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 para security.ldap.servers
.
Exemplo
Para se conectar a um servidor AD localizado em activedirectory.example.net
, inclua o seguinte no arquivo de configuração:
security: ldap: servers: "activedirectory.example.net"
MongoDB deve se vincular ao servidor AD para realizar query. Por padrão, o MongoDB usa o mecanismo de autenticação simples para se vincular ao servidor AD .
Alternativamente, você pode definir as seguintes configurações no arquivo de configuração para vincular ao servidor AD usando SASL
:
Definir
security.ldap.bind.method
comosasl
security.ldap.bind.saslMechanisms
, especificando uma sequência de mecanismos SASL separados por vírgula que o servidor AD suporta.
Este tutorial usa o mecanismo de autenticação LDAP simple
padrão.
Configure o MongoDB para autenticação Kerberos.
No arquivo de configuração MongoDB, defina security.authorization
para enabled
e setParameter
authenticationMechanisms
para GSSAPI
Para habilitar a autenticação via Kerberos, inclua o seguinte no arquivo de configuração:
security: authorization: "enabled" setParameter: authenticationMechanisms: "GSSAPI"
Configure o Modelo de Query LDAP para autorização.
No arquivo de configuração MongoDB, defina security.ldap.authz.queryTemplate
para um RFC4516 modelo de URL de query LDAP formatado.
No modelo, você pode usar:
{USER}
espaço reservado para substituir o nome de usuário autenticado na URL de consulta do 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. (Disponível a partir da versão 4,2)
Crie o modelo de query para recuperar os grupos do usuário.
Observação
Uma descrição completa da RFC4515, RFC4516, ou as queries do AD estão fora do escopo deste tutorial. O fornecido neste tutorial é apenas um exemplo queryTemplate
e pode não ser aplicável à sua implantação específica do AD .
Exemplo
O seguinte modelo de query retorna quaisquer grupos que listem {USER}
como membro, seguindo associações de grupo recursivas. Esta query LDAP pressupõe que os objetos de grupo rastreiem a associação do usuário armazenando o Nome Distinto (DN) do usuário completo usando o member
atributo . 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 os filtros de pesquisa LDAP.
security: ldap: authz: queryTemplate: "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"
Usando o modelo de query, o MongoDB substitui {USER}
pelo nome de usuário autenticado para fazer query no 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 em queryTemplate
, substituindo o token {USER}
pelo nome de usuário autenticado. 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 CN=dba,CN=Users,DC=example,DC=com
e CN=engineering,CN=Users,DC=example,DC=com
.
O MongoDB mapeia cada nome diferenciado de grupo retornado para um role no reconhecimento de data center admin
. Para cada nome diferenciado de grupo mapeado, se houver uma role no admin
reconhecimento de data center cujo nome corresponda exatamente ao nome diferenciado, o MongoDB concederá ao usuário as roles e os privilégio atribuídos a essa role.
A regra de correspondência LDAP_MATCHING_RULE_IN_CHAIN
exige o fornecedor do nome diferenciado completo do usuário de autenticação. Como o Kerberos requer autenticação com o userPrincipalName
de um usuário, você deve transformar os nomes de usuário de entrada em DNs usando o security.ldap.userToDNMapping
. A próxima etapa fornece orientação sobre como transformar os nomes de usuário recebidos para oferecer suporte ao queryTemplate
.
Transforme os nomes de usuário recebidos para autenticação via Active Directory.
No arquivo de configuração MongoDB, defina userToDNMapping
para transformar o nome de usuário fornecido pelo usuário de autenticação em um nome diferenciado do AD para dar suporte ao queryTemplate
.
Exemplo
A seguinte configuração do userToDNMapping
utiliza o filtro de expressão regular do match
para capturar o nome de usuário fornecido. O MongoDB insere o nome de usuário capturado no modelo de query ldapQuery
antes de executar a query.
security: ldap: userToDNMapping: '[ { match : "(.+)", ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})" } ]'
Você deve modificar a configuração de amostra fornecida para corresponder ao seu sistema. 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 à sua implantação do AD .
Exemplo
Um usuário autentica como alice@ENGINEERING.EXAMPLE.COM
. O MongoDB primeiro aplica quaisquer transformações especificadas em userToDNMapping
. Com base na configuração fornecida, o MongoDB captura o nome de usuário no estágio match
e executa uma query 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
.
O MongoDB então executa a query LDAP configurada no 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 userToDNMapping
substitution
o parâmetro transformar o nome do grupo, o resultado da substituição deverá ser um RFC4514 string que escapou.
Configurar credenciais de query.
O MongoDB requer credenciais para executar query no servidor AD .
Defina as seguintes configurações no arquivo de configuração:
security.ldap.bind.queryUser
, especificando o usuário Kerberos 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"
Em 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 queries LDAP em nome do MongoDB.
Opcional: adicione definições de configuração adicionais.
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implementação ou se os membros da implementação forem executados em hosts diferentes, especifique a configuração net.bindIp
.
Inicie o servidor MongoDB com autenticação Kerberos e autorização do Active Directory.
Inicie o servidor MongoDB com a opção --config
, especificando o caminho para o arquivo de configuração criado durante este procedimento. Se o servidor MongoDB estiver atualmente em execução, faça os preparos apropriados para parar o servidor.
Linux MongoDB Servers
No Linux, você deve especificar a variável de ambiente KRB5_KTNAME
, especificando o caminho para o arquivo keytab do servidor MongoDB.
env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>
Microsoft Windows MongoDB Servers
No Windows, você deve iniciar o MongoDB Server como a conta principal de serviço conforme configurado anteriormente no procedimento:
mongod.exe --config <path-to-config-file>
Conecte-se ao servidor MongoDB.
Conecte ao servidor MongoDB, autenticando como um usuário cuja associação de grupo direta ou transitiva corresponde a uma função MongoDB no banco de dados do admin
com userAdmin
, userAdminAnyDatabase
ou uma função personalizada com privilégios equivalentes.
Use mongosh
para autenticar no servidor MongoDB, defina as seguintes opções:
--host
com o nome de host do servidor MongoDB--port
com a porta do servidor MongoDB--username
para o usuáriouserPrincipalName
--password
para a senha do usuário (ou omita para quemongosh
solicite a senha)--authenticationMechanism
para"GSSAPI"
--authenticationDatabase
para"$external"
Exemplo
Anteriormente neste procedimento, você configurou o papel dn:CN=dba,CN=Users,DC=example,DC=com
no banco de dados do admin
com as permissões exigidas. Esta função corresponde a um grupo AD . Com base nos usuários configurados do AD, você pode se autenticar como usuário sam@dba.example.com
e receber as permissões necessárias.
mongosh --username sam@DBA.EXAMPLE.COM --password --authenticationMechanisms="GSSAPI" --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.
Os sistemas do Windows MongoDB devem usar mongo.exe
em vez de mongosh
.
Com os usuários do Active Directory configurados , o usuário autentica com êxito e recebe as permissões apropriadas.
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
). Isto exige que o setParameter
authenticationMechanisms
do servidor MongoDB inclua SCRAM-SHA-1
e/ou SCRAM-SHA-256
conforme apropriado.
Crie roles para mapear grupos AD retornados.
Para cada grupo no servidor AD que você deseja usar para a autorização MongoDB, você deve criar uma função correspondente no reconhecimento de data center admin
do MongoDB Server.
Exemplo
A operação a seguir cria uma função com o nome do 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 de Active Directory configurados, o MongoDB concede a um usuário que se autentica como sam@DBA.EXAMPLE.COM
ou alice@ENGINEERING.EXAMPLE.COM
a função readWrite
no banco de dados PrimaryApplication
.
Observação
Para gerenciar funções no banco de dados admin
, você deve ser autenticado como um usuário com userAdmin
no admin
, userAdminAnyDatabase
ou um papel personalizado com privilégios equivalentes.
Opcional: faça a transição dos usuários existentes do $external
para o servidor Active Directory.
Se atualizar uma instalação existente com usuários configurados no reconhecimento de data center do $external
, você deverá atender os seguintes requisitos para cada usuário para garantir o acesso após configurar o MongoDB para autenticação Kerberos 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 roles no banco de dados
admin
nomeadas para os grupos AD do usuário, de modo 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 AD CN=marketing,CN=Users,DC=example,DC=com
, 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 read
operações nos bancos de dados web_analytics
e PrimaryApplication
.
Importante
Ao configurar um papel para um grupo AD correspondente, lembre-se que todos os usuários com associação neste grupo podem receber os privilégios e papéis atribuídos. Considere a aplicação do princípio do menor privilégio ao configurar roles do MongoDB, gruposdo AD ou associação a grupos.
Se quiser continuar permitindo que os usuários em bancos de dados 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
.
setParameter: authenticationMechanisms: "GSSAPI,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.
Este 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: "GSSAPI"
Importante
A configuração de amostra fornecida requer modificação para corresponder ao esquema do AD , à estrutura de diretórios e à configuração. 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 roles e privilégios, consulte:
Teste e verificação
Após completar as etapas de configuração, você pode validar sua configuração com a ferramenta mongokerberos
.
mongokerberos
fornece um método conveniente para verificar a configuração Kerberos da sua plataforma para uso com o MongoDB e para testar se a autenticação Kerberos de um cliente MongoDB funciona conforme o esperado. Consulte a documentação do mongokerberos
para mais informações.
mongokerberos
está disponível apenas no MongoDB Enterprise.