Skip to main content
Si vous rencontrez des problèmes avec votre connecteur AD/LDAP, consultez les sections ci-dessous pour savoir comment résoudre les problèmes courants.

​
Exécutez l’outil de dépannage

Vous pouvez exécuter l’outil de dépannage dans la console d’administration du connecteur AD/LDAP, ou à l’extérieur de celle-ci en exécutant le programme manuellement. Pour détecter les problèmes de certificats, définissez la variable CONNECTIONS_API_V2_KEY dans le fichier de configuration du connecteur AD/LDAP.

​
Dans la console d’administration

Vous pouvez exécuter l’outil de dépannage dans la console d’administration.
  1. Accédez à la vue Dépannage pour consulter les journaux.
    Écran de dépannage de la console d’administration du connecteur AD/LDAP
  2. Sélectionnez Exécuter pour détecter les problèmes les plus courants liés au connecteur AD/LDAP.

​
En dehors de la console d’administration

Vous pouvez lancer l’outil de dépannage en dehors de la console d’administration.

​
Windows

Sur un poste Windows, exécutez le fichier de commandes fourni pour lancer l’outil de dépannage.
  1. Repérez le dossier du connecteur AD/LDAP (AD LDAP Connector).
  2. Exécutez le fichier troubleshoot.cmd.
Par exemple : C:\Program Files (x86)\Auth0\AD LDAP Connector\troubleshoot.cmd.
Écran de l’outil de dépannage du connecteur AD/LDAP

​
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. Accédez au dossier du connecteur AD/LDAP (AD LDAP Connector).
  3. Exécutez la commande node troubleshoot.js.

​
Problèmes d’installation et de configuration

Après avoir cliqué sur Save, la console d’administration du connecteur AD/LDAP exécute une série de tests pour valider les renseignements fournis. Les résultats de ces tests s’affichent sous l’en-tête Configuration log. La console d’administration exécute les tests suivants :
  • Test 1 : Tente d’établir une connexion TCP au serveur LDAP et au port spécifiés. Si le test 1 échoue, vérifiez la connectivité réseau de base et les paramètres du pare-feu qui pourraient empêcher cette connexion.
  • Test 2 : Tente d’effectuer une liaison LDAP auprès du serveur LDAP et du port spécifiés à l’aide du nom d’utilisateur et du 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 l’annuaire 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 l’annuaire cible.
  • Test 4 : Tente d’établir une connexion au serveur Auth0. Si le test 4 échoue, vérifiez la connectivité réseau et les paramètres du pare-feu qui pourraient empêcher cette connexion.

​
Problèmes courants et solutions

Vous trouverez ci-dessous une description de plusieurs problèmes courants et de leurs solutions.

​
Le traitement des requêtes d’authentification prend trop de temps

Par défaut, le connecteur AD/LDAP Auth0 importe les appartenances aux groupes d’un utilisateur depuis Active Directory et les inclut dans l’objet user. Ce comportement oblige le connecteur AD/LDAP à effectuer des requêtes supplémentaires auprès d’Active Directory, ce qui peut augmenter considérablement la durée du processus d’authentification. Si vous n’avez pas besoin que les groupes soient renvoyés dans le profil utilisateur, Auth0 recommande de désactiver explicitement la variable GROUPS dans le fichier de configuration du connecteur AD/LDAP.

​
L’utilisation du processeur de l’hôte est élevée

Si l’utilisation du processeur sur la machine qui héberge le connecteur AD/LDAP est constamment élevée (par exemple, si elle dépasse 60 % sur une période prolongée), plusieurs stratégies d’atténuation sont possibles.

​
Désinstaller les services non essentiels

Désinstallez tous les services non essentiels sur la machine hôte qui pourraient utiliser des ressources processeur.

​
Modifier la configuration d’importation des groupes

Si vous n’avez pas besoin que les groupes soient renvoyés dans le profil utilisateur, désactivez l’importation des groupes comme décrit dans Le traitement des requêtes d’authentification est trop long. Si vous avez besoin que les groupes soient renvoyés dans le profil utilisateur, examinez les groupes renvoyés dans les profils utilisateur d’Auth0. Les requêtes sur des groupes imbriqués et récursifs peuvent entraîner une forte utilisation du processeur. Si possible, testez en désactivant l’importation des groupes afin d’évaluer l’impact des requêtes liées aux groupes. Pour atténuer cet impact, corrigez toute attribution de groupe récursive ou autrement 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 qui utilisent le connecteur AD/LDAP a augmenté depuis son déploiement initial. Vous pouvez l’évaluer à l’aide de votre propre solution de surveillance, ou obtenir une estimation à partir du rapport Auth0 sur les utilisateurs actifs.
Dans les environnements Microsoft Windows Server, Microsoft System Center Operations Manager (SCOM) peut être configuré pour surveiller l’état du service du connecteur AD/LDAP et générer des alertes. Pour en savoir plus, consultez Surveiller le connecteur AD/LDAP avec System Center Operations Manager.
Si le nombre d’utilisateurs actifs a augmenté et que toutes les étapes ci-dessus ont déjà été suivies, vous devrez peut-être augmenter les capacités matérielles de votre machine hôte ou configurer un environnement de 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 vous constatez un décalage d’horloge, vous verrez un résultat comme celui-ci dans l’utilitaire de dépannage et 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
Assurez-vous que l’horloge de votre serveur est à l’heure. Si l’heure n’est pas exacte, les requêtes d’authentification échoueront. Vous pouvez corriger ce problème en veillant à ce que le système soit correctement configuré pour interroger un serveur de synchronisation au moyen du protocole Network Time Protocol (NTP). Dans les environnements Windows, le fournisseur NTP correspond habituellement au contrôleur de domaine lui-même. Assurez-vous que votre contrôleur de domaine est synchronisé avec un service externe. Pour savoir comment synchroniser votre environnement Active Directory avec un serveur de temps externe, consultez How to configure NTP server in Active Directory, Step by step on renanrodrigues.com. Si vous ne savez pas si l’horloge de votre serveur est synchronisée avec NTP, accédez à https://nist.time.gov et comparez l’heure affichée sur cette page avec celle du serveur sur lequel le connecteur s’exécute. Vous ne devriez pas constater plus d’une (1) seconde d’écart entre les deux.

​
Aucune connexion à Active Directory

Le connecteur AD/LDAP doit être installé sur un serveur qui peut joindre votre serveur LDAP. Lorsque des pare-feu et des connexions VPN s’interposent entre le connecteur AD/LDAP et le serveur LDAP, vous pourriez rencontrer des problèmes de connectivité. Si vous configurez un réseau Windows avec Active Directory, utilisez la commande nltest. Par exemple, pour vérifier si un ordinateur précis peut joindre le domaine fabrikam.local, utilisez nltest /dsgetdc:fabrikam.local. Pour voir à quel domaine le serveur actuel est connecté, utilisez nltest /dsgetdc:. Si un domaine n’existe pas ou n’est pas accessible, nltest renverra le message d’erreur suivant : Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN.

​
Message d’erreur UNABLE_TO_VERIFY_LEAF_SIGNATURE (cloud privé)

Cette erreur s’applique au connecteur AD/LDAP utilisé avec le cloud privé. Ce message d’erreur se produit lorsque le connecteur AD/LDAP ne parvient pas à démarrer, car il ne peut pas valider le certificat SSL configuré dans le cloud privé. Cela peut se produire lorsque le certificat racine (ou un certificat intermédiaire) est absent du magasin de certificats de la machine (Windows). Pour corriger ce problème, importez la chaîne de certificats dans le magasin de certificats Local Machine > Trusted Root de la machine sur laquelle le connecteur AD/LDAP est installé.

​
Connecteur derrière un proxy

Si la machine qui héberge le connecteur est derrière un proxy, vous pouvez définir une variable d’environnement système HTTP_PROXY, ou 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.
Si vous définissez des variables d’environnement système ou modifiez le fichier de configuration du connecteur AD/LDAP, vous devez redémarrer le connecteur AD/LDAP pour que les modifications prennent effet.
L’URL HTTP_PROXY doit être celle du proxy lui-même et ne peut pas pointer vers un fichier .pac (configuration automatique). Si votre proxy est configuré au moyen d’un fichier .pac, téléchargez ce fichier et repérez-y l’URL du proxy. Un proxy mal configuré peut entraîner plusieurs erreurs, comme Auth0 servers not reachable et SELF_SIGNED_CERT_IN_CHAIN. Si vous avez configuré une URL de proxy et redémarré le connecteur AD/LDAP, mais que vous voyez toujours des erreurs SELF_SIGNED_CERT_IN_CHAIN, 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, consultez Proxy auto config (PAC) on Wikipedia.

​
Aucune connexion Internet

Assurez-vous que votre serveur peut se connecter à votre locataire Auth0 (https://{yourDomain}). Pour le vérifier, ouvrez un navigateur et accédez à https://{yourDomain}/test.

​
Autorisations du compte de service

Le compte de service utilisé pour configurer le connecteur AD/LDAP doit disposer de l’autorisation read sur le serveur AD/LDAP et pouvoir interroger les groupes auxquels appartiennent les utilisateurs.

​
Problèmes liés à Kerberos

Pour activer la journalisation détaillée des requêtes Kerberos :
  1. Ajoutez DEBUG=kerberos-server comme variable d’environnement système.
  2. Redémarrez le connecteur AD/LDAP.
  3. Ouvrez une session.
  4. Consultez les journaux pour obtenir plus d’informations.
Si Kerberos est activé, mais que vos utilisateurs doivent quand même saisir leur nom d’utilisateur et leur mot de passe, vérifiez que le paramètre d’adresse IP est correctement configuré. Pour en savoir plus, consultez Configurer l’authentification du connecteur AD/LDAP avec Kerberos.

​
Les modifications du profil utilisateur dans AD ne sont pas immédiatement répercuté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 identifiants de l’utilisateur et son profil.
  2. Connecteur AD/LDAP : met en cache l’appartenance d’un utilisateur à des groupes.
La configuration de ces paramètres détermine à quel délai les modifications apportées à votre annuaire peuvent se répercuter dans le profil utilisateur lorsqu’il se connecte à vos applications. Dans certaines installations AD/LDAP, la synchronisation des attributs utilisateur peut prendre quelques minutes.

​
Mise en cache sur le serveur Auth0

Le serveur Auth0 met en cache le dernier profil de l’utilisateur authentifié avec succès, y compris le hachage de son nom d’utilisateur et de son mot de passe. Ce cache est activé par défaut, mais peut être désactivé. L’objectif de ce cache de premier niveau est de maximiser la disponibilité des transactions d’authentification lorsque AD n’est pas disponible, par exemple en cas de panne réseau. Il n’est activé que si le connecteur AD/LDAP ou les serveurs AD/LDAP ne sont pas disponibles.

​
Mise en cache dans le connecteur AD/LDAP

Le connecteur AD/LDAP met en cache les appartenances d’un utilisateur à des groupes. La durée de vie de ce cache est déterminée par la variable GROUPS_CACHE_SECONDS dans le fichier de configuration du connecteur AD/LDAP, avec une valeur par défaut de 600 secondes. L’objectif de ce cache de deuxième niveau est de réduire le temps d’exécution. Par défaut, le connecteur AD/LDAP récupère récursivement toutes les appartenances d’un utilisateur à des groupes, ce qui peut être une opération coûteuse dans certaines installations AD/LDAP. Ce cache est supprimé chaque fois que vous redémarrez le connecteur AD/LDAP.

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

Pour éviter d’avoir à ouvrir un port entrant sur vos serveurs, le connecteur AD/LDAP crée une connexion WebSocket vers un nœud disponible du cluster de serveurs d’Auth0 et la maintient ouverte pour recevoir 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 afin de permettre l’exécution des processus de déploiement internes. Le connecteur AD/LDAP détecte la fermeture de la connexion et met fin au processus, ce qui permet à la pile de services de le redémarrer, de créer une nouvelle connexion vers un nœud disponible et de reprendre les opérations. Pour éviter toute interruption, activez le cache :
  1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez le type de connexion Active Directory/LDAP.
  2. Sélectionnez votre connexion AD/LDAP.
  3. Passez à la vue Applications, puis activez la connexion pour la ou les applications souhaitées.
  4. Sélectionnez Save.

​
Erreur « postUrl is required »

Vous pourriez rencontrer cette erreur si vous n’avez pas effectué la configuration supplémentaire requise pour un domaine personnalisé. Pour utiliser des connexions AD/LDAP avec la prise en charge de Kerberos, vous devez mettre à jour le point de terminaison Ticket afin qu’il fonctionne avec le  :
  1. Ouvrez le fichier de configuration du connecteur AD/LDAP.
  2. Définissez la variable de configuration PROVISIONING_TICKET sur https://{yourDomain}/p/ad/jUG0dN0R.
  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 ne soit pas présente sur votre machine.
  • Si votre locataire se trouve dans l’environnement de nuage public, vérifiez que le certificat ISRG Root X1 se trouve dans le magasin de certificats de confiance de la machine sur laquelle le connecteur AD/LDAP est installé.
  • Si vous êtes dans 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 de haute disponibilité et que vous obtenez cette erreur sur une machine supplémentaire, vérifiez que les autorités de certification racines de confiance de cette machine correspondent à celles de la machine initiale.

​
Contacter l’assistance Auth0

Si vous ne parvenez pas à résoudre vous-même l’un de ces problèmes, communiquez avec l’assistance Auth0. Pour aider l’équipe d’assistance à diagnostiquer votre problème, incluez les éléments suivants dans votre billet d’assistance :
  1. Une 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. Le numéro de version de votre connecteur AD/LDAP.
    Écran de la console de dépannage du connecteur AD/LDAP

​
En savoir plus