Guia de Troubleshooting UCSM LDAP

Introdução

Este documento fornece a informação em validar a configuração do Lightweight Directory Access Protocol (LDAP) na suite de gerenciamento das comunicações unificadas (UCSM) e em etapas para investigar edições da falha da autenticação LDAP.

Manuais de configuração:

UCSM que configura a autenticação

Configuração do diretório ativo da amostra (AD)

Verifique a configuração ldap UCSM

Certifique-se que UCSM distribuiu a configuração com sucesso verificando o estado da máquina de estado finito (FSM) e mostra terminado em 100%.

Do contexto do comando line interface(cli) UCSM

ucs # scope security
ucs /security # scope ldap 
ucs /security/ldap # show configuration
ucs /security/ldap # show fsm staus

Do contexto do sistema operacional do nexo (NX-OS) CLI

ucs # scope security 
ucs(nxos)# show ldap-server
ucs(nxos)# show ldap-server groups

Melhores prática da configuração ldap

1. Crie domínios adicionais da autenticação em vez “do reino em mudança de Authenitcation nativo”

2. Use sempre a esfera local para do “a autenticação console”, caso que o usuário é travado para fora de usar “a autenticação nativa”, admin ainda poderia alcançá-lo do console.

3. UCSM falha sempre de volta à autenticação local se todos os server no autêntico-domínio dado não responderam durante a tentativa de login (não aplicável para o comando aaa do teste).

Validando a configuração ldap

Teste a autenticação LDAP usando o comando NX-OS. do “o comando aaa teste” está disponível somente da interface CLI NX-OS.

1. Valide a configuração do específico do grupo LDAP.

O comando seguinte examina a lista de todos os servidores ldap configurados baseados em sua ordem configurada.

ucs(nxos)# test aaa group ldap <username> <password>

2. Valide a configuração de servidor ldap específica

ucs(nxos)# test aaa server ldap <LDAP-server-IP-address> <username> <password>

NOTA: a corda do <password> será indicada no terminal.

Neste caso, UCSM testa a autenticação contra o server específico e pode falhar se não há nenhum filtro configurado para o servidor ldap especificado.

Pesquisando defeitos falhas no login LDAP

Esta seção fornece a informação em diagnosticar problemas da autenticação LDAP.

Cenário do problema #1 - Não pode entrar

Não pode entrar como o usuário LDAP através da interface gráfica de usuário (GUI) UCSM e do CLI

O usuário recebe o “erro que autentica ao server” ao testar a autenticação LDAP.

(nxos)# test aaa server ldap <LDAP-server> <user-name> <password>
error authenticating to server
bind failed for <base DN>: Can't contact LDAP server

Recomendação
Verifique a conectividade de rede entre o servidor ldap e a interface de gerenciamento da interconexão da tela (FI) pelo sibilo do Internet Control Message Protocol (ICMP) e conexão Telnet do estabelecimento do contexto de local-Mgmt

ucs# connect local
ucs-local-mgmt # ping <LDAP server-IP-address OR FQDN>
ucs-local-mgmt # telnet <LDAP-Server-IP-Address OR FQDN> <port-number> 

Investigue a conectividade de rede do Protocolo IP se UCSM não pode sibilar o servidor ldap ou abrir a sessão de Telnet ao servidor ldap.

Verifique se o Domain Name Service (DNS) retorna o endereço IP de Um ou Mais Servidores Cisco ICM NT correto ao UCS para o hostname do servidor ldap e certifique-se de que o tráfego LDAP não está obstruído entre estes dois dispositivos.

Cenário do problema #2 - Pode registrar no GUI, não pode registrar no SSH

O usuário LDAP pode entrar através de UCSM GUI mas não pode abrir a sessão SSH ao FI. 

Recomendação

Ao estabelecer a sessão SSH ao FI como o usuário LDAP, UCSM exige o “ucs” ser prepended antes do Domain Name LDAP

* Da máquina de Linux/MAC 

ssh ucs-<domain-name>\\<username>@<UCSM-IP-Address>
ssh -l ucs-<domain-name>\\<username> <UCSM-IP-address>
ssh <UCSM-IP-address> -l ucs-<domain-name>\\<username>

* Do cliente da massa de vidraceiro

Login as: ucs-<domain-name>\<username>

NOTA: O Domain Name é diferenciando maiúsculas e minúsculas e deve combinar o Domain Name configurado em UCSM. O comprimento username do máximo pode ser 32 carvões animais que inclui o Domain Name.

“ucs-<domain-name> \ <user-name>” = 32 carvões animais.

Cenário do problema #3 - O usuário tem privilégios de leitura apenas

O usuário LDAP pode entrar mas ter privilégios de leitura apenas mesmo que os mapas do LDAP-grupo sejam configurados corretamente em UCSM.

Recomendação
Se nenhum papel foi recuperado durante o processo de login LDAP, é permitido ao usuário remoto com padrão-papel (acesso do read only) ou acesso negado (nenhum-início de uma sessão) entrar a UCSM, com base na política do remote login.

Quando o usuário remoto entra e o usuário esteve dado o acesso somente leitura, nesse caso verifique os detalhes da sociedade de grupo de usuário em LDAP/AD.
Por exemplo, nós podemos usar o utilitário de ADSIEdit para o diretório ativo MS. ou ldapserach em caso de Linux/Mac.

Pode-se igualmente verificar com do “comando aaa teste” do shell NX-OS.

Cenário do problema #4 - Não pode entrar com “autenticação remota”

O usuário não pode entrar nem tem o acesso somente leitura a UCSM como o usuário remoto quando “a autenticação nativa” foi mudada ao mecanismo de autenticação remota (LDAP etc.) 

Recomendação
Como o fallsback UCSM à autenticação local para o acesso de console quando não pode alcançar o server da autenticação remota, nós podemos seguir abaixo das etapas para recuperá-lo.

1. Desligue o cabo de interface do mgmt do FI preliminar (o estado do conjunto da mostra indicaria qual está atuando como preliminar)
2. Conecte ao console do FI preliminar
3. Execute comandos seguintes mudar a autenticação nativa

scope security
show authentication
set authentication console local
set authentication default local
commit-buffer

4. Conecte o cabo de interface do mgmt
5. Entre através de UCSM usando a conta local e crie o autêntico-domínio para o grupo da autenticação remota (LDAP ex).
NOTA: Desligar a relação do mgmt não afetaria nenhum tráfego plano dos dados.

Cenário do problema #4 - Trabalhos da autenticação LDAP mas não com o SSL permitido

A autenticação LDAP está trabalhando muito bem sem Secure Socket Layer (SSL) mas falha quando a opção de SSL é permitida.

Recomendação
O cliente de LDAP UCSM usa os confiança-pontos configurados (Certificados do Certificate Authority (CA)) ao estabelecer a conexão SSL.

1. Certifique-se que o confiança-ponto esteve configurado corretamente.

2. O campo da identificação no CERT deve ser o “hostname “do servidor ldap. Certifique-se que o hostname configurado em UCSM combina o hostname atual no certificado e é válido.

3. Certifique-se que UCSM está configurado com “IP address” do “hostname” não do servidor ldap e é recheable da relação de local-Mgmt.

Cenário do problema #5 - A autenticação falha depois que o fornecedor LDAP muda

A autenticação falha após ter suprimido do servidor ldap velho e ter adicionado o servidor ldap novo 

Recomendação
Quando o LDAP está sendo usado no reino, na supressão e em adicionar da autenticação de server novos não é permitido. Da versão do 2.1 UCSM, conduziria à falha FS.

As etapas a seguir quando remover/que adiciona server novos na mesma transação for

1. Certifique-se que todos os reinos da autenticação que usam o ldap estão mudados ao local e salvar a configuração.
2. Atualize os servidores ldap e verifique que o estado FS terminou com sucesso.
3. Mude os reinos do AUTH dos domínios alterados em etapa 1, ao LDAP.

Para todos cenários do problema restantes - Debugando o LDAP

Gire sobre debuga, tentam entrar como o usuário LDAP e recolher depois dos logs junto com o techsupport UCSM que captura o evento falhado do início de uma sessão.

1) Abra uma sessão SSH ao FI e o início de uma sessão como o usuário local e mude-os ao contexto NX-OS CLI.

ucs # connect nxos 

2) O seguimento Enable debuga bandeiras e salvar a sessão SSH output ao arquivo de registro.

ucs(nxos)# debug aaa all <<< not required, incase of debugging authentication problems.
ucs(nxos)# debug aaa aaa-requests

ucs(nxos)# debug ldap all <<< not required, incase of debugging authentication problems.
ucs(nxos)# debug ldap aaa-request-lowlevel
ucs(nxos)# debug ldap aaa-request

3) Agora abra um GUI ou uma sessão CLI nova e tente entrar como o usuário (LDAP) remoto
4) Uma vez que você recebeu a mensagem da falha no login, gire fora debuga.

ucs(nxos)# undebug all

Caputure do pacote do tráfego LDAP

Nas encenações onde a captura de pacote de informação é exigida, no Ethanalyzer possa usado para capturar o tráfego LDAP entre o FI e o servidor ldap.

ucs(nxos)# ethanalyzer local interface mgmt capture-filter "host <LDAP-server-IP-address>" detail limit-captured-frames 0 write /bootflash/sysdebug/diagnostics/test-ldap.pcap

No comando acima, o arquivo do pcap salvar sob o diretório de /workspace/diagnostics e pode ser recuperado do FI através do contexto de local-Mgmt CLI

Acima do comando pode ser usado para capturar pacotes para todo o (LDAP, TACACS, RAIO) tráfego remoto do authenitcation.
5. Relevante entra o pacote do techsupport UCSM

No techsupport UCSM, os logs relevantes são ficados situados sob o diretório <FI>/var/sysmgr/sam_logs

httpd.log
svc_sam_dcosAG
svc_sam_pamProxy.log 

NX-OS commands or from <FI>/sw_techsupport log file

ucs-(nxos)# show system internal ldap event-history errors 
ucs-(nxos)# show system internal ldap event-history msgs 
ucs-(nxos)# show log

Advertências conhecidas

CSCth96721
o rootdn do servidor ldap em sam deve reservar mais do que os caráteres 128

A versão UCSM mais cedo do que o 2.1 tem uma limitação de 127 caráteres para a base DN/corda do ligamento DN.

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/cli/config/guide/2.0/b_UCSM_CLI_Configuration_Guide_2_0_chapter_0111.html#task_0FC4E8245C6D4A64B5A1F575DAEC6127

--------- pique ----------
O nome destacado específico na hierarquia LDAP onde o server deve começar uma busca quando um usuário remoto entra e o sistema tenta obter o DN do usuário baseado em seu username. O comprimento apoiado máximo da corda é 127 caráteres.
----------------------------

A edição é fixada em 2.1.1 e acima da liberação


CSCuf19514
O demónio LDAP causou um crash

O cliente de LDAP pode causar um crash ao inicializar a biblioteca SSL se o atendimento dos ldap_start_tls_s toma mais de 60 segundos para terminar a iniciação. Isto podia acontecer somente em caso da entrada de DNS/atrasos inválidos na resolução de DNS.

Tome etapas para endereçar os atrasos e os erros da resolução de DNS.