Muito bem, vamos falar sobre solução de problemas do LDAP. Para começar, o primeiro problema que você talvez tenha que solucionar é relacionado às falhas de validação.
É aí que, se o certificado não estiver correto, se o grupo não estiver configurado corretamente no servidor Active Directory ou OpenLDAP, se o nome de usuário não for digitado no formato correto, você poderá ver todos esses problemas.
Portanto, se a senha estiver incorreta para o usuário de consulta, você verá que ela diz "Failed to validate LDAP configuration details" e você não poderá pressionar o botão "Submit".
Uma coisa que quero destacar é que, quando você carrega o certificado aqui, o "AD-cert.cer" que você vê lá, o que o ACM faz com ele é que, quando você clica no botão "Validate", ele basicamente o armazena no "Diretório de certificados", localizado na barra "User local data protection", gerenciador de configuração server_data certificados.
Agora, depois que o certificado é armazenado lá, o ACM também converte esse certificado do formato ".cer" para o formato ".pem". Agora, fiz outro vídeo para mostrar como seria uma validação bem-sucedida.
Se houver falha na validação, o que você pode procurar no registro para solucionar o problema? Vamos continuar.
Então, para fazer isso novamente, vá para "Logs Directory", Escape, shift G e, em seguida, Escape, procure por configurar o LDAP em um equipamento.
Depois de procurá-lo, ele deve levá-lo à mensagem como esta, onde ele está tentando fazer o "testLDAPconnection". Se você rolar um pouco mais para baixo, ele fará um teste de ping e, em seguida, verificará se o usuário foi autenticado com sucesso e se é um membro do grupo.
Você verá uma mensagem como esta: Conexão LDAP testada com sucesso. Agora vamos analisar os registros de falha na validação de LDAP. Vamos ver a autenticação com falha.
Aqui, digito os detalhes e, propositalmente, tentarei inserir um dos campos incorretos como valor incorreto. Vejamos o que vai acontecer. Como é uma autenticação segura, vamos marcar esta caixa de seleção.
Carregaremos o certificado e, em seguida, tentaremos validá-lo. Parece que a validação falhou. Você pode passar o mouse sobre essa exclamação vermelha. A mensagem exibida é "Failed to validate LDAP configuration details".
Então, novamente, vá para "ACM logs directory", visualize "server.log", mude G para ir até o final do log, ? e, em seguida, procure por isso, LDAP Util: testConnection, com "C" maiúsculo, uma palavra.
Você verá uma mensagem como esta, e fica claro que foi um problema com o nome de usuário ou a senha. Nesse caso, foi um problema de senha, e vemos que a conexão de teste falhou.
Vamos ver algumas das pegadinhas para saber quando você está inserindo algumas dessas informações. Assim, quando for solicitado o nome de host do servidor ou o nome de host do LDAP, os usuários devem fornecer o "FQDN" ou o nome de domínio totalmente qualificado. Os endereços IP não funcionam.
Consulte o nome de usuário, os usuários devem fornecer o nome de usuário no formato de nome "User Principal". Um exemplo seria "Abc@domain.com", que sempre funciona.
Configurações do grupo de administradores. Agora, esse é o grupo de administradores configurado no nível do Active Directory ou OpenLDAP. Quando criam o grupo, esse é o seu cliente, e eles precisam garantir que o escopo do grupo seja definido como "Global" e o tipo deve ser "Security".
O nome de usuário da consulta deve ser um membro do grupo de administração LDAP. Geralmente, a prática recomendada é usar letras minúsculas para todos os valores. Também temos um defeito de código que causa alguns problemas quando você está usando valores em maiúsculas, portanto, esteja ciente disso.
Para configurações seguras de LDAP, os usuários devem fornecer o certificado raiz da CA no formato ".cer". Por fim, o grupo aninhado não é permitido, o que significa que os usuários devem ser membros diretos do grupo de administração do LDAP.
Esse usuário sobre o qual estamos falando é o usuário da consulta LDAP. Por exemplo, você não pode ter um usuário de consulta LDAP como parte de um grupo e esse grupo estar inserido no grupo de administração. Isso não funcionará.
Há mais um requisito que gostaria de abordar. Para que a integração do LDAP funcione com sucesso no armazenamento de proteção ou no Data Domain, o usuário de consulta LDAP deve ter permissões de controle total "Criar/remover" para o objeto de computador, pois, durante a integração, ele cria um objeto de computador.
Como fazer isso? No Active Directory, localize o usuário de consulta LDAP e vá para a "UO" pai, ou unidade organizacional, onde esse usuário reside. Clique com o botão direito do mouse nessa opção e clique em "Delegate Control". Ao fazer isso, será exibido um assistente como este. Você pode clicar em "Next", adicionar seu usuário, o usuário da consulta.
Em seguida, crie tarefas personalizadas a serem delegadas. E quando você fizer isso, você pode basicamente selecionar objetos de computador aqui e certifique-se de selecionar Criar objetos selecionados nesta pasta ou "Excluir". Depois de fazer isso, clique em "Next". Certifique-se de conceder privilégios de "controle total". Depois, clique em "Next" e "Finish".
Depois disso, você terá uma configuração tranquila no armazenamento de proteção ou também no Data Domain. Agora, quando se trata de solucionar problemas do tipo LDAP, é muito importante ir em uma ordem sistemática. Eu sempre recomendo começar com um teste de ping.
Garanta a conectividade usando o comando ping e sempre use o nome de host ou FQDN para o ping. Também sugiro o uso do endereço IP. Há um motivo para isso. Você pode emitir "ping -c". Execute quatro pacotes, então coloque o valor "4 FQDN" e, basicamente, você pode testar o ping e confirmar se ele foi bem-sucedido.
Eu disse para testar o ping para IP e nome de host porque às vezes o ping para IP funciona. No entanto, ele não funciona para o nome do host a partir do ACM ou de um ou mais componentes dentro do IDPA. O motivo para isso pode ser que o domínio de pesquisa DNS está ausente no arquivo "/etc/resolv.conf", o que pode causar falhas de ping no nome de host do servidor LDAP.
Pra ser sincero, este é o problema mais comum que acontece. Portanto, certifique-se sempre de que é possível fazer ping no endereço IP. No entanto, não é possível fazer ping no nome do host. Verifique o arquivo "/etc/resolv.conf" em cada um dos componentes IDPA. Certifique-se de ter esse domínio de pesquisa adicionado para o Active Directory ou para o ambiente para garantir que a resolução funcione.
Sugiro determinadas verificações de porta. Quais são os requisitos de porta para a integração de LDAP? Basicamente, exigimos as portas TCP 389 e 636 que devem estar abertas para comunicação entre os componentes do IDPA e o Active Directory ou o servidor "OPENLDAP". Agora, as portas TCP 88 e 464 devem estar abertas para autenticação Kerberos entre o software de proteção, que é o seu "Avamar", o armazenamento de proteção, que é o seu Data Domain, e o servidor do Active Directory ou "OPENLDAP".
Como você testaria a conectividade da porta? Você pode fazer isso usando o comando "curl". Vimos isso na demonstração. Assim, você pode emitir "curl -kv", o "FQDN_OF_LDAP_SERVER": o número da porta. Lembre-se de que 389 é para "não seguro" e 636 é para "seguro". Após a emissão, você vai ver o que está procurando. Conectado a "dc.x400.sh" na "porta 636". Solução de problemas usando "ldapsearch", acho que é uma ferramenta muito importante.
Isso pode ser usado se a validação estiver falhando, se a configuração estiver falhando. Como o que ele faz é semelhante a uma "validação", em que ele está basicamente usando os detalhes de LDAP que você tem, ele executará uma conexão de teste e confirmará se podemos nos conectar ou não. Basicamente, "ldapsearch" é uma ferramenta de linha de comando que abre uma conexão com um servidor LDAP, vincula-se a ele e realiza uma pesquisa usando um filtro.
Os resultados são exibidos no formato "LDIF" ou no formato LDAP Interchange. A ferramenta ldapsearch pode ser usada em componentes do IDPA, como ACM, DPC Search, Avamar etc., para testar a conexão com o servidor LDAP e validar as configurações. A sintaxe é diferente para LDAP não seguro e seguro.
Para não seguro, você pode emitir o comando "ldapsearch -h". Coloque o FQDN do servidor LDAP, seja OpenLDAP ou Active Directory. Em "-p", Coloque o número da porta lá, "-D", coloque as credenciais do usuário LDAP_Query adicione "x400.sh", por exemplo, ou algo nesse formato, -b, você coloca o "Base_DN" É aí que o componente de domínio vai. Algo como "dc=x400, dc=2.sh." Em seguida, em "-W", coloque a senha de consulta.
Da mesma forma, para LDAP seguro, você também pode fazer isso. ldapsearch -h, ldaps://, coloque a URL lá. Então, você coloca o número "LDAP_server_FQDN: port". Quando você está configurando o tipo LDAP seguro, é "openssl" ou validando os certificados. Você pode fazer isso emitindo o comando "openssl". Execute "openssl s_client -connect". Insira o FQDN do servidor OPENLDAP do Active Directory: o número da porta, que é 636.
Observe que aparece o status "Connected". Isso significa que o ACM foi capaz de validar e se conectar na porta 636 com esse certificado. Ao emitir este comando, ele mostra as mensagens "unable to validate the change" ou "verify the change". Isso é bom, porque o que você está estabelecendo uma conexão, você não está passando um certificado para o servidor Active Directory para validar a cadeia etc. Portanto, isso é bom. Esta saída acima estava truncada, por isso, tenha atenção a isso.
Vamos ver a validação dos detalhes do usuário de consulta e do grupo de administradores. Digamos que você descubra que certas coisas não estão certas, talvez o grupo não esteja certo, os detalhes para o usuário de consulta não estejam certos, e é aí que você passa para a próxima etapa de solução de problemas. O que fazer? Use o PowerShell no servidor do Active Directory, que pode ser consultado para buscar os objetos de usuário e o grupo no formato DN, ou Nome distinto.
Portanto, você tem o cmdlet "Get-ADUser", que obtém um objeto de usuário especificado, ou executa uma pesquisa para obter vários objetos de usuário. Você tem o cmdlet "Get-ADGroup", que pode ser usado para obter um grupo, ou executar uma pesquisa para recuperar vários grupos de um Active Directory. Temos uma captura de tela da saída à esquerda para o usuário. À direita, para o grupo. Você pode ver o tipo de saída que apareceria.
Você verá o "DistinguishedName". Portanto, essa é uma "ldap.query". Ela está presente na UO "Users". O componente de domínio é "x400.sh" e, ao analisar isso, posso verificar o "UserPrincipalName". É isso que preciso inserir na janela pop-up ou caixa de diálogo "configure LDAP".
Portanto, você pode confirmar todos esses detalhes aqui. Agora, quando se trata de agrupar, você tem o formato DN e a localização do grupo. Ele está novamente na UO "Users". O componente de domínio é "x400" e "sh". A categoria do grupo é "Security". Lembre-se que eu disse que as categorias de grupo deveriam ser "Segurança" e o escopo do grupo deveria ser "Global". Isso algo que podemos validar a partir daqui.
Também mostra o "SamAccountName" e o nome do grupo, que é "dp_admin". Portanto, essa é uma boa maneira de validar também no nível do Active Directory dos clientes. Observe que, depois que o LDAP é configurado no IDPA, como disse nos slides anteriores, o ACM armazena os detalhes da configuração do LDAP no ldapconfig.xml. Ele também armazena a senha desse usuário de consulta em um arquivo chamado "Component Credentials.ReadXml".
A funcionalidade básica do ACM enquanto monitora os componentes é que, a cada poucos minutos, ele testará um login LDAP usando essas credenciais e detalhes para cada um dos componentes. Por que isso acontece? Ele deseja garantir que a configuração do LDAP esteja funcionando e se a senha de consulta do LDAP armazenada no ACM para esse usuário e os outros componentes está realmente sincronizada. Que não mudou, e é isso que ele verifica.
Agora, em casos de uso em que um cliente alterou a senha do usuário de consulta, sua autenticação LDAP deixará de funcionar em todos os componentes e na interface do usuário do ACM, você verá uma mensagem de erro dizendo "LDAP password out of sync". Então, se esse for o caso, você pode basicamente vir para a GUI do ACM clique no mesmo pop-up "Configure external LDAP" e você pode clicar nesta caixa de seleção que diz: Update external LDAP password.
Depois que quando fizer isso, você poderá ver todos os outros detalhes esmaecidos e apenas atualizar a senha. Em seguida, ele atualizará a senha por conta própria ou no arquivo ACM "Component Credentials.ReadXml" que armazena as credenciais. Além disso, também atualizará a senha de configuração em cada um dos produtos ou componentes de ponto do IDPA para garantir que a autenticação ainda funcione. É preciso ter atenção a isso.
Um dos motivos mais comuns para a falha na configuração ou os usuários estarem tendo algum tipo de problema de autenticação pode ser porque o horário não está sincronizado. A hora é muito importante. Quando se trata de LDAP, o horário deve estar sincronizado entre os componentes do IDPA e o Active Directory ou o servidor OpenLDAP. Os usuários podem experimentar falhas de configuração, e até mesmo falhas de login de autenticação, se o tempo estiver fora de sincronia.
Usamos isso todos os dias. Os locais de registro e os próprios arquivos de registro, o que são? Portanto, ao solucionar problemas de LDAP, os usuários devem analisar o seguinte log on ACM para verificar se há erros de configuração, integração, validação e monitoramento, e esse é o seu "server.log".
Vimos isso na demonstração. Agora, se, digamos, houver uma falha de configuração em um ou mais componentes, precisaremos analisar os registros nesse componente específico em que a configuração do LDAP falhou, bem como o "server.log" do ACM. Aqui estão os locais dos logs. No ACM, temos o "server.log". Na Data Protection Central, temos "elg.log".
Esta é a parte inteira fornecida aqui. Temos Search. Esse termo tem "cis.log". O software de proteção tem seu "userauthentication.log". Há algumas instâncias em que você também pode encontrar alguns detalhes sobre "mcserver.log.0", que está no mesmo local.
No caso do Protection Storage ou Data Domain, você pode analisar o log "messages.engineering" e precisará de acesso Bash para isso. Lembre-se disso. Por fim, DPA. Você pode ver o "server.log", que é um diretório opt/emc/dpa/services/logs.
