Dépannage du Connecteur AD/LDAP

Si vous rencontrez des problèmes avec votre Connecteur AD/LDAP, lisez ce qui suit pour savoir comment résoudre les problèmes les plus courants.

Exécuter l’outil de dépannage

Vous pouvez exécuter l’outil de dépannage dans Admin Console du Connecteur AD/LDAP ou sans passer par l’Admin Console et en exécutant le programme manuellement.

Pour détecter les problèmes liés aux certificats, définissez la variable CONNECTIONS_API_V2_KEY dans le fichier de configuration du Connecteur AD/LDAP.

Dans Admin Console

Vous pouvez exécuter l’outil de dépannage dans Admin Console.

  1. Passez à la vue Dépannage pour lire les journaux.

    Troubleshoot AD/LDAP Connector Admin Console Troubleshooting Screen
  2. Sélectionnez Exécuter pour détecter les problèmes les plus courants liés au Connecteur AD/LDAP.

Sans passer par Admin Console

Vous pouvez lancer l’outil de dépannage sans utiliser Admin Console

Windows

Dans un environnement Windows, exécutez le fichier de commande fourni pour lancer l’outil de dépannage.

  1. Repérez le dossier AD/LDAP Connector (AD LDAP Connector).

  2. Exécutez le fichier troubleshoot.cmd.

Par exemple : C:\Program Files (x86)\Auth0\AD LDAP Connector\troubleshoot.cmd.

Troubleshoot AD/LDAP Connector Troubleshooting Tool Screen

Linux

Sur une machine Linux, exécutez le programme Node.js fourni pour lancer l’outil de dépannage.

  1. Ouvrez une nouvelle fenêtre de terminal.

  2. Changez le répertoire de travail pour celui du dossier AD/LDAP Connector (AD LDAP Connector).

  3. Exécutez la commande node troubleshoot.js.

Problèmes d’installation et de configuration

Après avoir cliqué sur Enregistrer, l'Admin Console du Connecteur AD/LDAP effectue une série de tests pour valider les informations fournies. Les résultats des tests sont affichés sous le titre Journal de configuration.

Admin Console effectue les tests suivants :

  • Test 1 : Tente d’établir une connexion TCP au serveur LDAP sur le port spécifié. Si le test 1 échoue, vérifiez la connectivité de base du réseau et les paramètres du pare-feu qui pourraient empêcher cette connexion.

  • Test 2 : Tente d’effectuer une liaison LDAP sur le serveur LDAP et le port spécifiés, avec le nom d’utilisateur et le mot de passe fournis. Si le test 2 échoue, vérifiez la chaîne de connexion LDAP, le chemin de recherche, le nom d’utilisateur et le mot de passe.

  • Test 3 : Tente d’effectuer une recherche LDAP dans le répertoire pour vérifier les privilèges du nom d’utilisateur spécifié. Si le test 3 échoue, vérifiez les privilèges du nom d’utilisateur dans le répertoire cible.

  • Test 4 : Tente d’établir une connexion avec le serveur Auth0. Si le test 4 échoue, vérifiez la connectivité du réseau et les paramètres du pare-feu qui pourraient empêcher une telle connexion.

Problèmes courants et solutions

Les descriptions de plusieurs problèmes courants et leurs solutions sont décrites ci-dessous.

Le traitement des demandes d’authentification est trop long

Par défaut, le Connecteur AD/LDAP Auth0 importe les appartenances d’un utilisateur à un groupe depuis Entra ID et les inclut dans l’objet user.

Ce comportement oblige le Connecteur AD/LDAP à effectuer des requêtes supplémentaires dans Entra ID, ce qui peut allonger considérablement la durée du processus d’authentification.

Si vous n’avez pas besoin que les groupes soient renvoyés sur le profil utilisateur, Auth0 vous recommande de désactiver explicitement la variable GROUPS dans le fichier de configuration du Connecteur AD/LDAP.

L’utilisation de la CPU de l’hôte est élevée

Si l’utilisation de la CPU sur la machine hébergeant le Connecteur AD/LDAP est constamment élevée (par exemple, une utilisation soutenue supérieure à 60 %), il existe plusieurs stratégies d’atténuation.

Désinstaller les services non critiques

Désinstallez tous les services non critiques sur la machine hôte qui peuvent consommer des cycles de CPU.

Modifier la configuration de l’importation de groupes

Si vous n’avez pas besoin que les groupes soient renvoyés dans le profil utilisateur, désactivez l’importation de groupes comme décrit dans Le traitement des demandes d’authentification est trop long.

Si vous avez besoin que les groupes soient renvoyés sur le profil utilisateur, examinez les groupes renvoyés sur les profils utilisateurs Auth0. Les requêtes sur les groupes imbriqués et récursifs peuvent entraîner une utilisation élevée de la CPU. Si possible, testez avec l’importation de groupes désactivée pour évaluer l’impact des requêtes de groupes.

Pour atténuer l’impact, corrigez toute affectation de groupe récursive ou problématique dans votre serveur AD/LDAP, et/ou augmentez la valeur de la variable GROUPS_CACHE_SECONDS dans le fichier de configuration du Connecteur AD/LDAP.

Évaluer le volume d’utilisateurs actifs

Vérifiez si le nombre d’utilisateurs actifs utilisant le Connecteur AD/LDAP a augmenté depuis son déploiement initial. Vous pouvez évaluer cela en utilisant votre propre solution de surveillance, ou vous pouvez obtenir une estimation à partir du rapport des utilisateurs actifs d’Auth0.

Si le nombre d’utilisateurs actifs a augmenté et que toutes les étapes ci-dessus ont déjà été suivies, il se peut que vous deviez mettre à niveau les spécifications matérielles de votre machine hôte ou configurer un environnement à haute disponibilité.

Décalage d’horloge

Le connecteur exige que l’horloge du serveur soit synchronisée avec le service Auth0. Le seuil maximal autorisé est de 5 secondes.

Si un décalage d’horloge existe, vous verrez des résultats comme celui-ci dans l’outil de dépannage et dans les journaux du connecteur :

12:18:55 - info: * Testing clock skew...
12:18:55 - error: × Clock skew detected:
12:18:55 - error: > Local time: 2020-05-04 12:18:55
12:18:55 - error: > Auth0 time: 2020-05-04 12:19:10

Was this helpful?

/

Assurez-vous que l’horloge de votre serveur est à jour. Si l’heure n’est pas correcte, les demandes d’authentification échoueront. Pour y remédier, il faut s’assurer que le système est correctement configuré pour interroger un serveur de synchronisation via le protocole de synchronisation réseau (NTP). Dans les environnements Windows, le fournisseur NTP est généralement le même contrôleur de domaine. Assurez-vous que votre contrôleur de domaine est synchronisé avec un service externe.

Pour savoir comment synchroniser votre environnement Entra ID avec un serveur de temps externe, lisez Comment configurer un serveur NTP dans Entra ID, étape par étape disponible sur renanrodrigues.com.

Si vous n’êtes pas sûr que l’horloge de votre serveur est synchronisée via le protocole NTP, rendez-vous à l’adresse URL https://nist.time.gov et comparez l’heure sur cette page avec l’heure du serveur sur lequel le Connecteur fonctionne. Il ne devrait pas y avoir plus d’une (1) seconde de décalage entre les deux.

Pas de connexion à Entra ID

Le Connecteur AD/LDAP doit être installé sur un serveur qui peut accéder à votre serveur LDAP. Vous pouvez rencontrer des problèmes de connectivité lorsque des pare-feu et des connexions VPN sont placés entre le Connecteur AD/LDAP et le serveur LDAP.

Si vous configurez un réseau Windows avec Entra ID, utilisez la commande nltest. Par exemple, pour tester si une machine spécifique peut atteindre le domaine fabrikam.local, utilisez nltest /dsgetdc:fabrikam.local.

Pour savoir à quel domaine le serveur actuel est connecté, utilisez nltest /dsgetdc:.

Si un domaine n’existe pas ou ne peut être atteint, nltest renverra un message d’erreur : Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN.

Message d’erreur « UNABLE_TO_VERIFY_LEAF_SIGNATURE » (Nuage privé)

Cette erreur s’applique au Connecteur AD/LDAP en combinaison avec le nuage privé.

Ce message d’erreur se produit lorsque le Connecteur AD/LDAP ne démarre pas parce qu’il ne peut pas valider le certificat SSL configuré dans le nuage privé. Cela peut se produire lorsque le certificat racine (ou tout certificat intermédiaire) est manquant dans le Magasin de certificats de la machine (Windows). Pour résoudre ce problème, importez la chaîne de certificats dans le Magasin de certificats Local Machine > Trusted Root sur la machine sur laquelle le Connecteur AD/LDAP est installé.

Connecteur derrière un proxy

Si la machine hébergeant le Connecteur est derrière un proxy, vous pouvez définir une variable d’environnement système HTTP_PROXY, ou vous pouvez définir la variable HTTP_PROXY dans le fichier de configuration du Connecteur AD/LDAP. Si vous utilisez un proxy authentifié, l’URL doit être au format http://USERNAME:PASSWORD@SERVER_URL:PORT.

L’URL HTTP_PROXY doit être l’URL du proxy lui-même et ne peut pas pointer vers un fichier (auto-config) .pac. Si votre proxy est configuré via un fichier .pac, téléchargez le fichier .pac et trouvez-y l’URL du proxy.

Un proxy mal configuré peut entraîner plusieurs erreurs, telles que les erreurs Auth0 servers not reachable et SELF_SIGNED_CERT_IN_CHAIN.

Si vous avez configuré une URL de proxy et redémarré le serveur du Connecteur AD/LDAP, mais que les erreurs SELF_SIGNED_CERT_IN_CHAIN persistent, assurez-vous que votre serveur fait confiance au certificat racine du proxy. Sur une machine Windows, vous pouvez le vérifier en ouvrant certmgr.msc et en recherchant le certificat de votre proxy. Pour en savoir plus, lisez l’article « Fichier .PAC » sur Wikipédia.

Aucune connectivité Internet

Assurez-vous que votre serveur peut se connecter à votre locataire Auth0 (https://{yourDomain}).

Pour vérifier cela, ouvrez un navigateur et naviguez vers https://{yourDomain}/test.

Autorisations du compte de service

Le compte de service utilisé pour configurer le Connecteur AD/LDAP doit disposer des autorisations read sur le serveur AD/LDAP et doit être capable d’interroger les groupes pour les utilisateurs.

Problèmes liés à Kerberos

Pour activer la journalisation détaillée des demandes Kerberos :

  1. Ajoutez DEBUG=kerberos-server comme variable d’environnement système.

  2. Redémarrez le Connecteur AD/LDAP.

  3. Connectez-vous.

  4. Vérifiez les journaux pour plus d’informations.

Si Kerberos est activé, mais que vos utilisateurs sont invités à saisir leur nom d’utilisateur et leur mot de passe, vérifiez que le paramètre d’adresse IP est correctement configuré. Pour plus d’informations, consultez Configurer l’authentification du Connecteur AD/LDAP avec Kerberos.

Les modifications apportées au profil utilisateur dans AD ne sont pas immédiatement reflétées dans l’application

Le Connecteur AD/LDAP utilise deux niveaux de mise en cache configurables :

  1. Serveur Auth0 : Met en cache à la fois les informations d’identification de l’utilisateur et son profil.

  2. Connecteur AD/LDAP : Met en cache l’appartenance d’un utilisateur à un groupe.

La configuration de ces paramètres détermine la rapidité avec laquelle les modifications apportées dans votre répertoire peuvent être reflétées dans le profil d’un utilisateur lorsqu’il se connecte à votre (vos) application(s). Dans certaines installations AD/LDAP, la synchronisation des attributs des utilisateurs peut prendre quelques minutes.

Mise en cache sur le serveur Auth0

Le serveur Auth0 met en cache le dernier profil authentifié avec succès de l’utilisateur, notamment un hachage de son nom d’utilisateur et de son mot de passe. Cette mise en cache est activée par défaut et peut être désactivée.

L’objectif de ce cache de premier niveau est de maximiser la disponibilité des transactions d’authentification lorsqu’AD n’est pas disponible, par exemple lors d’une panne de réseau. Il n’est activé que si le Connecteur AD/LDAP ou le(s) serveur(s) AD/LDAP sont indisponibles.

Mise en cache dans le Connecteur AD/LDAP

Le Connecteur AD/LDAP met en cache les appartenances d’un utilisateur à un groupe. La durée de vie de ce cache est déterminée par la variable GROUPS_CACHE_SECONDS du fichier de configuration du Connecteur AD/LDAP, avec une valeur par défaut de 600 (secondes).

L’objectif de ce cache de second niveau est de réduire le temps d’exécution. Par défaut, le Connecteur AD/LDAP récupère de manière récursive toutes les appartenances de groupe d’un utilisateur, ce qui peut être un processus coûteux dans certaines installations AD/LDAP. Ce cache est supprimé chaque fois que vous redémarrez le serveur sur lequel est installé le Connecteur AD/LDAP.

Le Connecteur redémarre après le message « auth0: Connection closed. » dans le journal.

Pour éviter de devoir ouvrir un port d’entrée dans vos serveurs, le Connecteur AD/LDAP crée une connexion WebSocket à un nœud disponible dans la grappe de serveurs d’Auth0 et la maintient ouverte pour écouter les messages entrants d’Auth0.

Environ une fois par jour (bien que la fréquence puisse varier dans certaines circonstances), chaque nœud de serveur met fin à la connexion pour permettre aux processus de déploiement interne de se dérouler. Le Connecteur AD/LDAP détecte la fermeture de la connexion et met fin au processus, ce qui permet à la pile de services de redémarrer le processus, de créer une nouvelle connexion avec un nœud disponible et de reprendre les opérations.

Pour éviter tout temps d’arrêt, activez le cache :

  1. Allez dans Auth0 Dashboard > Authentification > Entreprise, et sélectionnez le type de connexion Active Directory/LDAP.

  2. Sélectionnez votre connexion AD/LDAP.

  3. Passez à la vue Applications et activez la connexion pour la ou les applications souhaitées.

  4. Sélectionnez Enregistrer.

Erreur « postUrl is required »

Vous pourriez rencontrer cette erreur si vous n’avez pas terminé la configuration supplémentaire d’un domaine personnalisé.

Afin d’utiliser les connexions AD/LDAP avec une prise en charge de Kerberos, vous devrez mettre à jour le point de terminaison Billet pour qu’il fonctionne avec le domaine personnalisé :

  1. Ouvrez le fichier de configuration du Connecteur AD/LDAP.

  2. Définissez https://{yourDomain}/p/ad/jUG0dN0R pour la variable de configuration PROVISIONING_TICKET.

  3. Redémarrez le Connecteur AD/LDAP.

Impossible de vérifier localement le certificat de l’émetteur

Si vous recevez l’erreur UNABLE_TO_GET_ISSUER_CERT_LOCALLY après avoir configuré un Connecteur AD/LDAP, il se peut que l’autorité de certification soit absente de votre machine.

  • Si votre locataire se trouve dans un environnement de nuage public, vérifiez que vous disposez du certificat ISRG Root X1 dans votre Magasin de certificats de confiance sur la machine sur laquelle le Connecteur AD/LDAP est installé.

  • Si vous utilisez l’environnement de plateforme convergée, ajoutez le certificat ISRG Root X2 au Magasin de certificats de confiance de la machine sur laquelle le Connecteur AD/LDAP est installé.

Si vous configurez un environnement à haute disponibilité et que vous rencontrez cette erreur sur une machine supplémentaire, vérifiez que les autorités de certification racine de confiance sur la machine supplémentaire correspondent aux autorités de certification racine de confiance sur la machine initiale.

Contacter le support Auth0

Si vous ne parvenez pas à résoudre l’un de ces problèmes par vous-même, contactez le Support Auth0.

Pour aider l’équipe de support à résoudre votre problème, incluez les éléments suivants dans votre ticket de support :

  1. Description du problème.

  2. Une exportation de vos fichiers de configuration AD/LDAP.

  3. Une copie du ou des fichiers journaux du service :

    • Windows : C:\Program Files (x86)\Auth0\AD LDAP Connector\logs.log

    • Linux : /var/log/auth0-adldap.log

  4. Numéro de version de votre Connecteur AD/LDAP.

    Troubleshoot AD/LDAP Connector Console Screen

En savoir plus