Intéressons-nous au dépannage de LDAP. Pour commencer, l'un des premiers problèmes que vous devrez sans doute résoudre concerne les échecs de validation.
C’est là que si votre certificat n’est pas correct, si votre groupe n’est pas correctement configuré sur le serveur Active Directory ou OpenLDAP, si votre nom d’utilisateur n’est pas entré dans le bon format, vous pouvez voir tous ces problèmes.
Ainsi, si le mot de passe est incorrect pour l’utilisateur de la requête, le message « Échec de la validation des détails de configuration LDAP » s’affiche, et vous ne pouvez pas appuyer sur le bouton « Submit ».
Une chose que je tiens à souligner, c’est que lorsque vous téléchargez le certificat ici, le « AD-cert.cer » que vous voyez là, ce qu’ACM en fait, une fois que vous cliquez sur le bouton « Validate », il le stocke dans le « Certificates Directory » qui se trouve dans la barre « User local data protection », le gestionnaire de configuration server_data les certificats.
Une fois le certificat stocké, ACM convertit également ce certificat du format « .cer » au format « .pem ». Maintenant, j’ai réalisé une autre vidéo pour voir à quoi ressemblerait une validation réussie.
Et en cas d'échec de validation, quels sont les éléments que vous pourriez rechercher dans le journal à des fins de dépannage ? C'est ce que nous allons voir.
Donc, pour le faire, accédez à nouveau au « Logs Directory », appuyez sur Escape, shift G, puis sur Escape, recherchez cette configuration LDAP sur une appliance.
Une fois que vous avez effectué cette recherche, vous devriez accéder à un message comme celui-ci, où il essaie d’effectuer la « testLDAPconnection ». Si vous faites défiler la page un peu plus loin, il effectue un test ping, puis vérifie si l’utilisateur a été authentifié avec succès et s’il est membre du groupe.
Vous verrez un message comme celui-ci : « La connexion LDAP a été testée avec succès. » Passons maintenant en revue les journaux correspondant à un échec de validation LDAP. Intéressons-nous à l'échec de validation.
Ici, je saisis les détails et je vais volontairement essayer de saisir l’un des champs incorrects comme valeur incorrecte. afin de voir ce que cela donne. Comme il s'agit d'un LDAP sécurisé, je coche cette case.
Nous allons charger le certificat, puis nous essaierons de le valider. Il semble que la validation ait échoué. En passant votre curseur sur ce point d'exclamation rouge, un message indiquant « Failed to validate LDAP configuration details » s'affiche.
Je reviens donc à « ACM logs directory », affichez « server.log », et maintenez la touche G pour aller à la fin du journal, ? , puis recherchez ceci, LDAP Util : testConnection, avec « C » majuscule, un mot.
Un message similaire à celui-ci s'affiche, indiquant clairement qu'il s'agissait d'un problème de nom d'utilisateur ou de mot de passe. Dans ce cas, il s'agissait d'un problème de mot de passe et nous constatons que le test de connexion a échoué.
Voyons maintenant quelques-uns des pièges à connaître quand vous saisissez certains de ces détails. Lorsque les utilisateurs sont invités à fournir un « Server Hostname » ou « LDAP Hostname », ils doivent fournir le nom de domaine complet ou FQDN. Les adresses IP ne fonctionnent pas.
Pour le nom d’utilisateur de la question, les utilisateurs doivent fournir le nom d’utilisateur au format « User Principal ». Par exemple, ils peuvent utiliser « Abc@domain.com », qui fonctionne tout le temps.
Paramètres du groupe d’administrateurs. Il s’agit du groupe d’administrateurs configuré au niveau d’Active Directory ou d’OpenLDAP. Lorsque votre client crée le groupe, il doit s'assurer que la portée du groupe est définie sur Global et le type sur Security.
« Query username » doit désigner un membre du groupe d'administration LDAP. Une bonne pratique consiste généralement à utiliser des minuscules pour toutes les valeurs. Nous avons également un défaut de code qui cause des problèmes lorsque vous utilisez des valeurs en majuscules, donc gardez cela à l’esprit.
Pour les configurations LDAP sécurisées, les utilisateurs doivent fournir un certificat d’autorité de certification racine au format « .cer ». Enfin, les groupes imbriqués n'étant pas autorisés, les utilisateurs doivent être directement membres du groupe d'administration LDAP.
Dans notre cas, il s'agit de l'utilisateur de requête LDAP. Par exemple, il n'est pas possible de définir un utilisateur de requête LDAP comme membre d'un groupe et ce groupe comme membre de ce groupe d'administration. Cela ne fonctionnera pas.
J'aimerais aborder une dernière exigence. Pour que l’intégration LDAP fonctionne correctement sur Protection Storage ou Data Domain, l’utilisateur de la requête LDAP doit disposer des autorisations de contrôle total « Créer/Supprimer » pour l’objet ordinateur, car lors de l’intégration, il crée un objet ordinateur.
Comment procéder ? Dans Active Directory, localisez l'utilisateur de requête LDAP et accédez à l'unité d'organisation (Organization Unit – OU) parente dans laquelle réside l'utilisateur. Cliquez dessus avec le bouton droit de la souris, puis cliquez sur Delegate Control. Un Assistant comme celui-ci s'affiche. Vous pouvez cliquer sur Next, puis ajouter l'utilisateur de requête.
Ensuite, créez une tâche à déléguer personnalisée. Dans ce cas, vous pouvez sélectionner les objets Ordinateur ici et vous assurer de sélectionner Créer les objets sélectionnés dans ce dossier ou « Supprimer ». Une fois que vous avez terminé, vous pouvez cliquer sur Next. Assurez-vous de lui accorder les privilèges avec un contrôle total, puis cliquez sur Next et Finish.
Une fois que vous aurez fait cela, vous vous assurerez d’avoir une configuration fluide du côté de Protection Storage ou Data Domain. Maintenant, lorsqu’il s’agit de résoudre des problèmes de type LDAP, il est très important d’aller dans un ordre systématique. Je recommande toujours de commencer par un test ping.
Vérifiez la connectivité à l'aide de la commande ping et utilisez toujours pour celle-ci le nom d'hôte ou le FQDN. Je vous suggère d'utiliser également l'adresse IP, pour la simple raison que vous pouvez ainsi émettre une commande « ping -c », Émettez quatre paquets, mettez donc la valeur « 4 FQDN » et en gros, vous pouvez tester le ping et confirmer qu’il a réussi.
Si je recommande de tester la commande ping à la fois sur l'adresse IP et le nom d'hôte, c'est parce que la commande ping sur adresse IP fonctionne parfois. Toutefois, cela ne fonctionne pas pour créer un nom d’hôte à partir de l’ACM ou d’un ou de plusieurs composants au sein de l’IDPA. Cela peut s'expliquer par le fait que le domaine de recherche DNS est manquant dans le fichier « /etc/resolv.conf », ce qui peut entraîner des échecs de la commande ping sur le nom d'hôte du serveur LDAP.
Honnêtement, c'est le problème le plus courant que nous rencontrons. Vérifiez donc toujours si vous pouvez exécuter une commande ping sur l'adresse IP, mais pas sur le nom d'hôte. Vérifiez le fichier « /etc/resolv.conf » sur chacun des composants IDPA. Assurez-vous que vous avez ajouté ce domaine de recherche pour Active Directory ou pour l’environnement afin de vous assurer que la résolution fonctionne.
Ensuite, je suggère d'effectuer certaines vérifications de port. Quelles sont donc les exigences de port pour l'intégration LDAP ? Nous avons essentiellement besoin de ports TCP 389 et 636 qui doivent être ouverts pour la communication entre les composants IDPA et le serveur Active Directory ou « OPENLDAP ». À présent, les ports TCP 88 et 464 doivent être ouverts pour l’authentification Kerberos entre le logiciel de protection, qui est votre « Avamar », le stockage de protection, qui est votre système Data Domain, et le serveur Active Directory ou OPENLDAP.
Comment tester la connectivité des ports ? Il suffit d'utiliser la commande « curl », comme nous l'avons vu dans la démo. Ainsi, vous pouvez émettre la commande « curl -kv » suivie du FQDN du serveur LDAP, de deux points et du numéro de port. N'oubliez pas que le port 389 correspond à « non sécurisé » et le port 636 à « sécurisé ». Quand vous émettez cette commande, voici le résultat que vous devez obtenir : Connecté à « dc.x400.sh » sur le « port 636 ». La commande « ldapsearch » est un outil très important pour le dépannage.
Cela peut être utilisé si votre validation échoue, si votre configuration échoue. Étant donné que ce qu’il fait est similaire à une « validation » où il utilise essentiellement les détails LDAP dont vous disposez, il effectue un test de connexion et confirme si nous pouvons nous connecter ou non. Fondamentalement, « ldapsearch » est un outil de ligne de commande qui ouvre une connexion à un serveur LDAP, s’y lie et effectue une recherche à l’aide d’un filtre.
Les résultats s'affichent alors au format LDIF ou LDAP Interchange. L’outil ldapsearch peut être utilisé sur les composants IDPA tels que ACM, DPC Search, Avamar, etc., pour tester la connexion au serveur LDAP et valider les paramètres. Notez que la syntaxe est différente pour les LDAP non sécurisés et sécurisés.
Pour les LDAP non sécurisés, vous pouvez exécuter la commande ldapsearch -h. Indiquez le FQDN du serveur LDAP, qu'il s'agisse d'OpenLDAP ou d'Active Directory, suivi de « -p ». Mettez-y le numéro de port, « -D », mettez les informations d’identification de l’utilisateur, LDAP_Query ajoutez « x400.sh », par exemple, ou quelque chose de ce format, -b, vous mettez le « Base_DN » C’est là que le composant de domaine se trouve. Quelque chose comme « dc=x400, dc=2.sh. », puis « -w », suivi du mot de passe de la requête.
Pour le LDAP sécurisé, vous pouvez procéder de la même façon. ldapsearch -h, ldaps://, placez-y l’URL. Donc, vous mettez le numéro « LDAP_server_FQDN : port ». Lorsque vous configurez le type LDAP sécurisé, c’est « openssl » ou validez les certificats. Pour ce faire, exécutez la commande « openssl ». Exécutez « openssl s_client -connect ». Saisissez le FQDN du serveur Active Directory ou OPENLDAP, suivi de deux points et du numéro de port, à savoir 636.
Vous remarquerez que « CONNECTED » est affiché. Cela signifie qu’ACM a été en mesure de valider et de se connecter sur le port 636, avec ce certificat. Vous remarquerez peut-être en exécutant cette commande qu'elle indique « unable to validate the change » ou « verify the change ». Ce n'est pas un problème, car vous souhaitez simplement vous connecter et non transmettre un certificat pour que le serveur Active Directory valide la chaîne, etc. Là encore, n'oubliez pas que la sortie ci-dessus a été tronquée.
À présent, intéressons-nous à la validation des détails de l'utilisateur de requête et du groupe d'administration. Supposons que vous découvriez que certaines choses ne vont pas, peut-être que le groupe n’est pas correct, que les détails de l’utilisateur de la requête ne sont pas corrects, et c’est là que vous passez à l’étape suivante du dépannage. Comment procéder ? Vous utilisez PowerShell sur le serveur Active Directory, qui peut être interrogé pour extraire les objets d'utilisateur et de groupe au format Distinguished Name (ou DN).
Vous avez donc votre commande cmdlet « Get-ADUser », qui obtient un objet d'utilisateur spécifié, ou effectue une recherche pour obtenir plusieurs objets d'utilisateur. Puis, vous avez votre commande cmdlet « Get-ADGroup », qui peut être utilisée pour obtenir un groupe, ou effectuer une recherche pour récupérer plusieurs groupes à partir d'un Active Directory. Nous avons une capture d'écran de la sortie sur la gauche pour l'utilisateur et sur la droite pour le groupe. Vous pouvez voir le type de sortie que vous recevrez.
Vous voyez le Distinguished Name. Il s'agit donc d'une « ldap.query », présente dans l'unité d'organisation « Users ». Le composant de domaine est « X400.sh », et rien qu'en regardant ces informations, je suis en mesure de vérifier l'UPN. C'est ce que je dois saisir dans la fenêtre contextuelle « configure LDAP » ou dans la boîte de dialogue.
Vous pouvez donc confirmer tous ces détails ici. Quand il s'agit de groupes, là encore, vous avez le format DN, et l'emplacement du groupe, toujours dans l'unité organisationnelle « Users ». Le composant de domaine est « x400 » et « sh ». La catégorie de groupe est « Security ». Rappelez-vous que je vous ai dit que les catégories de groupe devaient être « Sécurité » et que le périmètre du groupe devait être « Global ». Encore une fois, nous pouvons le confirmer d'ici.
On obtient aussi le « SamAccountName » et le nom du groupe, à savoir « dp_admin ». Il s’agit donc d’un bon moyen pour vous de valider également au niveau Active Directory des clients. Notez qu’une fois que le LDAP est configuré sur l’IDPA, comme je l’ai dit dans mes diapositives précédentes, ACM stocke les détails de la configuration LDAP dans ldapconfig.xml. Il stocke également le mot de passe de cet utilisateur de requête dans un fichier nommé « Component Credentials.ReadXml. »
Et ACM, pendant la surveillance des composants, a pour fonctionnalité de base de tester à intervalles réguliers une connexion LDAP à l'aide de ces informations d'identification et de ces détails pour chacun des composants. La raison à cela Il veut s’assurer que la configuration LDAP fonctionne et si le mot de passe de requête LDAP stocké sur l’ACM pour cet utilisateur et les autres composants est effectivement synchronisé. Il vérifie que ce mot de passe n'a pas changé.
Désormais, dans les cas d’utilisation où un client a modifié le mot de passe utilisateur de la requête, votre authentification LDAP cessera de fonctionner sur tous les composants et dans l’interface utilisateur d’ACM, vous verrez un message d’erreur indiquant « Mot de passe LDAP désynchronisé ». Si c’est le cas, vous pouvez accéder à l’interface utilisateur de l’ACM, cliquer sur la même fenêtre contextuelle « Configure external LDAP » et cliquer sur la case à cocher Update external LDAP password.
Ce faisant, tous les autres détails sont grisés et vous pouvez simplement mettre à jour le mot de passe. Le mot de passe est alors mis à jour ou le fichier « Component Credentials.ReadXml » d'ACM dans lequel sont stockées les informations d'identification est mis à jour. Il met également à jour le mot de passe de configuration sur chacun des produits ou composants ponctuels d'IDPA pour garantir le fonctionnement continu de l'authentification. C'est donc une opération très importante.
L’une des raisons les plus courantes pour lesquelles la configuration échoue ou que les utilisateurs rencontrent des problèmes d’authentification peut être que l’heure n’est pas synchronisée. L'heure est un paramètre très sensible Un paramètre, lorsqu’il s’agit de LDAP, l’heure doit être synchronisée entre les composants IDPA et le serveur Active Directory ou OpenLDAP. Les utilisateurs peuvent rencontrer des échecs de configuration, voire des échecs de connexion à l’authentification, si l’heure n’est pas synchronisée.
Abordons maintenant des éléments que nous utilisons au quotidien, à savoir les emplacements de journaux et les fichiers journaux eux-mêmes. Par conséquent, lors du dépannage des problèmes de LDAP, les utilisateurs doivent analyser l’ouverture de session suivante dans ACM pour détecter toute erreur de type configuration, intégration, validation et surveillance. C’est ainsi que vous avez « server.log ».
Nous l'avons vu également dans la démo. Maintenant, si, par exemple, il y a un échec de configuration sur un ou plusieurs composants, nous devons analyser les journaux sur ce composant particulier où la configuration LDAP a échoué, ainsi que le « server.log » de l’ACM. Voici les emplacements des journaux. Sur ACM, nous trouvons le fichier « server.log ». Sur Data Protection Central se trouve le fichier « elg.log ».
C'est le chemin complet qui est fourni ici. Dans le cas de Search, nous avons le fichier « cis.log ». Protection Software utilise le fichier « userauthentication.log ». Dans certains cas, vous pouvez trouver des détails dans le fichier « mcserver.log » également, qui se trouve au même emplacement.
Pour votre stockage de protection ou Data Domain, vous pouvez consulter le journal « messages.engineering » et vous aurez besoin d’un accès Bash pour cela, alors gardez cela à l’esprit. Pour finir, dans DPA se trouve Vous pouvez voir le « server.log », qui est un répertoire opt/emc/dpa/services/logs.
