Guide de dépannage LDAP UCSM

Introduction

Ce document fournit des informations sur la validation de la configuration LDAP (Lightweight Directory Access Protocol) sur Unified Computing System Manager (UCSM) et sur les étapes pour étudier les problèmes d'échec d'authentification LDAP.

Guides de configuration :

Configuration de l'authentification UCSM

Exemple de configuration Active Directory (AD)

Vérification de la configuration LDAP UCSM

Assurez-vous que UCSM a correctement déployé la configuration en vérifiant l'état FSM (Finite State Machine) et qu'il affiche terminé à 100 %.

À partir du contexte de l'interface de ligne de commande (CLI) UCSM

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

À partir du contexte de l'interface de ligne de commande Nexus Operating System (NX-OS)

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

Meilleures pratiques de configuration LDAP

1. Créer des domaines d'authentification supplémentaires au lieu de modifier le domaine d'authentification natif

2. Toujours utiliser le domaine local pour 'authentification de console'. Dans le cas où l'utilisateur est verrouillé pour utiliser 'authentification native', l'administrateur peut toujours y accéder à partir de la console.

3. UCSM revient toujours à l'authentification locale si tous les serveurs du domaine d'authentification donné n'ont pas répondu lors de la tentative de connexion (non applicable à la commande test aaa ).

Validation de la configuration LDAP

Testez l'authentification LDAP à l'aide de la commande NX-OS. La commande 'test aaa' est disponible uniquement à partir de l'interface CLI NX-OS.

1. Validez la configuration spécifique du groupe LDAP.

La commande suivante passe en revue la liste de tous les serveurs LDAP configurés en fonction de leur ordre configuré.

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

2. Valider la configuration spécifique du serveur LDAP

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

REMARQUE 1 : La chaîne <password> s’affiche sur le terminal.

REMARQUE 2 : L'adresse IP ou le nom de domaine complet du serveur LDAP doit correspondre à un fournisseur LDAP configuré.

Dans ce cas, UCSM teste l'authentification sur un serveur spécifique et peut échouer si aucun filtre n'est configuré pour le serveur LDAP spécifié.

Dépannage des échecs de connexion LDAP

Cette section fournit des informations sur le diagnostic des problèmes d'authentification LDAP.

Scénario de problème n°1 - Connexion impossible

Impossible de se connecter en tant qu'utilisateur LDAP via l'interface utilisateur graphique UCSM et l'interface de ligne de commande

L'utilisateur reçoit « Erreur d'authentification sur le serveur » lors du test de l'authentification 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

Recommandation
Vérifier la connectivité réseau entre le serveur LDAP et l'interface de gestion d'interconnexion de fabric (FI) par ping ICMP (Internet Control Message Protocol) et établir une connexion telnet à partir du contexte de gestion locale

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> 

Examinez la connectivité réseau IP (Internet Protocol) si UCSM ne peut pas envoyer de requête ping au serveur LDAP ou ouvrir une session telnet au serveur LDAP.

Vérifiez si le service DNS (Domain Name Service) renvoie l'adresse IP correcte à UCS pour le nom d'hôte du serveur LDAP et assurez-vous que le trafic LDAP n'est pas bloqué entre ces deux périphériques.

Scénario de problème n°2 : connexion à l'interface utilisateur graphique impossible, connexion SSH impossible

L'utilisateur LDAP peut se connecter via l'interface utilisateur UCSM mais ne peut pas ouvrir de session SSH à FI. 

Recommandation

Lors de l'établissement d'une session SSH à FI en tant qu'utilisateur LDAP, UCSM nécessite l'ajout de " ucs- " avant le nom de domaine LDAP

* À partir de la machine 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>

* À partir du client putty

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

NOTE: Le nom de domaine est sensible à la casse et doit correspondre au nom de domaine configuré dans UCSM. La longueur maximale du nom d'utilisateur peut être de 32 caractères qui incluent le nom de domaine.

« ucs-<domain-name>\<user-name>" = 32 caractères.

Scénario 3 - L'utilisateur dispose de privilèges en lecture seule

L'utilisateur LDAP peut se connecter mais dispose de privilèges en lecture seule même si les mappages de groupe LDAP sont correctement configurés dans UCSM.

Recommandation
Si aucun rôle n'a été récupéré au cours du processus de connexion LDAP, l'utilisateur distant est soit autorisé avec le rôle par défaut ( accès en lecture seule ), soit refusé l'accès ( non-connexion ) à UCSM, en fonction de la stratégie de connexion à distance.

Lorsque l'accès en lecture seule a été donné aux utilisateurs distants et aux utilisateurs, dans ce cas, vérifiez les détails de l'appartenance au groupe d'utilisateurs dans LDAP/AD.
Par exemple, nous pouvons utiliser l'utilitaire ADSIEDIT pour MS Active Directory. ou ldapserach dans le cas de Linux/Mac.

Il peut également être vérifié avec la commande " test aaa " du shell NX-OS.

Scénario de problème n°4 - Connexion impossible avec 'Authentification à distance'

L'utilisateur ne peut pas se connecter ou dispose d'un accès en lecture seule à UCSM en tant qu'utilisateur distant lorsque " Authentification native " a été remplacé par un mécanisme d'authentification à distance ( LDAP, etc. ) 

Recommandation
Comme UCSM revient à l'authentification locale pour l'accès à la console lorsqu'il ne peut pas atteindre le serveur d'authentification à distance, nous pouvons suivre les étapes suivantes pour le récupérer.

1. Déconnectez le câble d'interface de gestion de l'IF principal ( show cluster state indique lequel agit en tant que Primary ).
2. Se connecter à la console de l’IF principal
3. Exécuter les commandes suivantes pour modifier l'authentification native

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

4. Connexion du câble d'interface de gestion
5. Connectez-vous via UCSM à l'aide d'un compte local et créez un domaine d'authentification pour le groupe d'authentification à distance (ex LDAP).
NOTE: La déconnexion de l'interface de gestion n'affecterait AUCUN trafic du plan de données.

Scénario de problème n° 4 - L'authentification LDAP fonctionne mais pas avec SSL activé

L'authentification LDAP fonctionne correctement sans SSL (Secure Socket Layer) mais échoue lorsque l'option SSL est activée.

Recommandation
Le client LDAP UCSM utilise les points d'approbation configurés (certificats d'autorité de certification) lors de l'établissement de la connexion SSL.

1. Assurez-vous que le point d'approbation a été configuré correctement.

2. Le champ d'identification dans cert doit être " hostname " du serveur LDAP. Assurez-vous que le nom d'hôte configuré dans UCSM correspond au nom d'hôte présent dans le certificat et qu'il est valide.

3. Assurez-vous que UCSM est configuré avec 'hostname' et non 'ipaddress' du serveur LDAP et qu'il est récupérable à partir de l'interface de gestion locale.

Scénario de problème n°5 - L'authentification échoue après les modifications du fournisseur LDAP

Échec de l'authentification après suppression d'un ancien serveur LDAP et ajout d'un nouveau serveur LDAP 

Recommandation
Lorsque LDAP est utilisé dans le domaine d'authentification, la suppression et l'ajout de nouveaux serveurs ne sont pas autorisés. À partir de la version UCSM 2.1, cela entraînerait une défaillance FSM.

Les étapes à suivre lors de la suppression/ajout de nouveaux serveurs dans une même transaction sont les suivantes :

1. Assurez-vous que tous les domaines d'authentification utilisant ldap sont remplacés par local et sauvegardés dans la configuration.
2. Mettez à jour les serveurs LDAP et vérifiez que l'état FSM s'est terminé correctement.
3. Remplacez les domaines d'authentification des domaines modifiés à l'étape 1 par LDAP.

Pour tous les autres scénarios de problèmes - Débogage LDAP

Activez les débogages, essayez de vous connecter en tant qu'utilisateur LDAP et rassemblez les journaux suivants avec le support technique UCSM qui capture l'événement de connexion ayant échoué.

1) Ouvrez une session SSH pour FI et connectez-vous en tant qu'utilisateur local et passez au contexte CLI NX-OS.

ucs # connect nxos 

2) Activez les indicateurs de débogage suivants et enregistrez le résultat de la session SSH dans le fichier journal.

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) Ouvrez maintenant une nouvelle interface utilisateur graphique ou une nouvelle session CLI et essayez de vous connecter en tant qu'utilisateur LDAP distant
4) Une fois que vous avez reçu le message d'échec de connexion, désactivez les débogages.

ucs(nxos)# undebug all

Capture de paquets du trafic LDAP

Dans les scénarios où la capture de paquets est requise, Ethanalyzer peut être utilisé pour capturer le trafic LDAP entre FI et le serveur LDAP.

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

Dans la commande ci-dessus, le fichier pcap est enregistré dans le répertoire /workspace/diagnostics et peut être récupéré à partir de FI via le contexte CLI de gestion locale

La commande ci-dessus peut être utilisée pour capturer des paquets pour tout trafic d'authentification distant ( LDAP, TACACS, RADIUS ).
5. Journaux pertinents dans l'offre d'assistance technique UCSM

Dans le support technique UCSM, les journaux pertinents se trouvent dans le <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

Causes connues

CSCth96721
le routeur du serveur ldap sur sam doit comporter plus de 128 caractères

La version UCSM antérieure à la version 2.1 a une limite de 127 caractères pour la chaîne DN/DN de liaison de base.

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

— snip —
Nom unique spécifique dans la hiérarchie LDAP où le serveur doit commencer une recherche lorsqu'un utilisateur distant se connecte et que le système tente d'obtenir le nom de domaine de l'utilisateur en fonction de son nom d'utilisateur. La longueur maximale de la chaîne prise en charge est de 127 caractères.
—

Problème corrigé dans la version 2.1.1 et ultérieure


CSCuf19514
Démon LDAP endommagé

Le client LDAP peut se bloquer lors de l'initialisation de la bibliothèque ssl si l'appel ldap_start_tls_s prend plus de 60 secondes pour terminer l'initialisation. Cela ne peut se produire qu'en cas d'entrée DNS non valide / de retards dans la résolution DNS.

Prendre des mesures pour résoudre les retards et les erreurs de résolution DNS.