Résoudre les problèmes courants concernant GCDS

Si vous n'arrivez pas à faire aboutir une synchronisation, vérifiez l'exactitude des informations figurant dans le gestionnaire de configuration et réalisez les tests suivants pour identifier la source du problème :

1. Dans le gestionnaire de configuration, ouvrez le fichier XML vous servant à configurer la synchronisation.
2. Sur la page LDAP Connections (Connexions LDAP), cliquez sur Test Connections (Tester les connexions) pour voir si vous arrivez à vous connecter au serveur LDAP.
3. Sur la page Notifications, cliquez sur Test Notification (Notification test) pour vous assurer que l'envoi d'une notification test fonctionne.
4. Sur la page Sync (Synchronisation), cliquez sur Simulate Sync (Simuler la synchronisation) pour vous assurer que vous avez bien renseigné tous les champs requis et que la synchronisation fonctionne.

Dans de rares cas, le service d'assistance peut vous demander d'activer la journalisation HTTP complète en plus de la journalisation en mode Trace dans GCDS. La journalisation HTTP complète permet d'afficher la requête API exacte envoyée par GCDS et la réponse fournie par les API de Google.

Important : Les journaux HTTP complets peuvent contenir des informations hautement sensibles. Avant de les envoyer à l'assistance, supprimez toute information sensible telle que le contenu des champs "refresh_token" ou "access_token".

Pour activer la journalisation HTTP complète :

1. Vérifiez que GCDS n'est pas en cours d'exécution, via la commande sync-cmd ou le gestionnaire de configuration.
2. Accédez au dossier d'installation de GCDS.

3. Modifiez le fichier jre/lib/logging.properties.

4. Ajoutez les lignes suivantes à la fin du fichier :

   java.util.logging.FileHandler.pattern = %h/gcdshttp%u.%g.log
   java.util.logging.FileHandler.limit = 5000000
   java.util.logging.FileHandler.count = 100
   java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
   handlers = java.util.logging.FileHandler
   com.google.api.client.http.level = CONFIG
   
   com.google.gdata.client.http.HttpGDataRequest.level = ALL
   sun.net.www.protocol.http.HttpURLConnection.level = ALL

5. Enregistrez le fichier.
6. Exécutez une autre synchronisation GCDS en activant la journalisation en mode Trace.

   Des fichiers journaux nommés gcdshttp*.log sont créés dans le dossier "homedir" (Linux) ou "profil" (Microsoft Windows). Ces fichiers pouvant être très volumineux, veillez à les compresser dans une archive.

7. Supprimez les lignes que vous aviez ajoutées à l'étape 4 pour empêcher la création d'autres fichiers journaux volumineux à l'avenir.
8. Fournissez les fichiers suivants à l'assistance :
   • Fichier XML
   • Journaux en mode Trace et fichiers gcdshttp*.log générés lors de la dernière synchronisation

Dans un journal, la taille d'un corps de requête ou de réponse est limitée à 16 Ko. Si une entrée de journal est tronquée parce qu'elle dépasse cette limite, utilisez un proxy de débogage tel que Fiddler.

Pour ce faire, mettez à jour les fichiers .vmoptions afin que GCDS utilise le magasin de certificats de confiance Windows et désactivez les contrôles LRC. Définissez Fiddler en tant que serveur proxy dans GCDS (l'adresse IP est en principe 127.0.0.1 sur le port 8888). Si vous utilisez GCDS sous Linux, vous ne pouvez pas utiliser le magasin de certificats de confiance de Windows. Vous devez donc importer le certificat racine de Fiddler dans le magasin de confiance Java de GCDS. Pour en savoir plus sur cette procédure, consultez Résoudre les problèmes liés aux certificats.

Si vous rencontrez des problèmes lors de la configuration de l'hôte de relais SMTP pour vos notifications, suivez la procédure de dépannage suivante.

Échec de la connexion : message "Hôte SMTP inconnu"

1. Ouvrez une invite de commande.
2. Pour vérifier si le nom d'hôte configuré du serveur SMTP renvoie une adresse IP, saisissez la commande suivante :

   nslookup nom-hôte-smtp.com

Échec de la connexion : message "Impossible de se connecter à l'hôte SMTP"

Vérifiez si le serveur exécutant GCDS peut se connecter à l'hôte SMTP.

1. Pour vérifier la connexion, depuis la ligne de commande ou le terminal Windows, saisissez la commande suivante :

   telnet smtp.gmail.com 587

2. Si l'hôte ne parvient pas à se connecter, vérifiez les règles de pare-feu d'entrée du serveur SMTP et les règles de pare-feu de sortie du serveur GCDS.
3. Assurez-vous d'avoir autorisé le trafic sur le port SMTP.

Impossible de convertir le socket en erreur TLS dans les journaux

Désactivez les contrôles des listes de révocation de certificats (LRC). Pour en savoir plus, consultez Comment GCDS vérifie-t-il les listes de révocation de certificats ?.

Consultez Utiliser un fichier XML avec plusieurs machines ou utilisateurs pour découvrir comment ouvrir un fichier XML enregistré sur une autre machine, ou sur la même machine mais par un autre utilisateur.

Si les données LDAP des journaux GCDS en mode Trace ne correspondent pas à celles que vous espériez lire sur le serveur LDAP (par exemple, si un utilisateur est introuvable ou si un attribut n'est pas associé à la valeur appropriée), exportez les données de l'annuaire LDAP au format LDIF. L'assistance peut comparer les données avec les données LDAP des journaux GCDS.

Lorsque vous exportez les données, utilisez un éditeur de requêtes LDAP tel que ldapsearch (Linux) ou ldifde (Windows), et simulez les mêmes conditions que GCDS en exécutant :

• Définissez les mêmes paramètres de connexion que ceux configurés pour GCDS.
• Exécutez l'éditeur de requêtes sur la même machine que celle sur laquelle GCDS s'exécute.
• Utilisez le même nom d'utilisateur pour l'authentification LDAP de GCDS.

Exemple

Vos journaux GCDS n'affichent pas l'attribut mail de vos utilisateurs, et les paramètres de votre règle de recherche GCDS sont les suivants :

• DN de base : ou=Ireland,dc=altostrat,dc=com
• Portée : Sous-arborescence
• Filtre de recherche : (&(objectCategory=person)(objectClass=user))
• Serveur : dc01.altostrat.com
• Port : 636
• Protocole : LDAP+SSL
• DN l'utilisateur pour l'authentification : cn=GCDS,ou=Users,dc=altostrat,dc=com

Utilisez ces commandes :

• Linux : ldapsearch -v -b "ou=Ireland,dc=altostrat,dc=com" -s sub -h dc01.altostrat.com -p 636 -x -Z -D "cn=GCDS,ou=Users,dc=altostrat,dc=com" "(&(objectCategory=person)(objectClass=user))" mail givenname uniqueidentifier sn > out.ldif (Vous devrez peut-être modifier la commande en fonction de votre système.)
• Windows : ldifde -f out.ldif -s dc01.altostrat.com -v -t 636 -d "ou=Ireland,dc=altostrat,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -p SubTree -l mail,givenname,uniqueidentifier,sn -a "cn=GCDS,ou=Users,dc=altostrat,dc=com" PASSWORD (Remplacez la partie PASSWORD par le mot de passe de l'utilisateur LDAP défini dans GCDS.)

Si la sortie (out.ldif) ne contient pas l'attribut mail d'un utilisateur concerné, cela signifie qu'il y a un problème avec l'infrastructure LDAP. Cela peut être lié aux autorisations de l'utilisateur dont vous vous servez pour accéder au LDAP (par exemple, OpenLDAP et Active Directory permettent de définir des autorisations au niveau des attributs). Il est également possible que l'attribut ne soit pas répliqué sur le catalogue global si vous utilisez un port de catalogue global tel que 3268 ou 3269.

Si le résultat contient l'attribut mail pour un utilisateur concerné, fournissez les éléments suivants à l'assistance Google Workspace :

• Le fichier out.ldif
• Une capture d'écran de l'invite de commande ou de la fenêtre de terminal dans laquelle vous avez exécuté la commande
  (veillez à supprimer le mot de passe)
• Le journal en mode TRACE de GCDS

Pour que vous puissiez exécuter une simulation de synchronisation, votre serveur doit pouvoir envoyer des e-mails. Si vous exécutez GCDS sur un serveur de messagerie, vous pouvez utiliser l'adresse IP 127.0.0.1. Si ce n'est pas le cas, veuillez contacter l'administrateur de votre messagerie pour obtenir les informations appropriées.

Si la synchronisation ne démarre pas à l'aide de la ligne de commande, vérifiez que vous avez bien utilisé l'argument -o ou --oneinstance dans la ligne de commande.

Si vous utilisez l'un de ces arguments, GCDS crée un fichier LOCK (.lock) associé au fichier de configuration XML. Si un autre fichier LOCK se trouve sur le même serveur, GCDS n'exécute pas la synchronisation pour empêcher l'exécution simultanée de plusieurs instances de GCDS.

Si aucune autre instance de GCDS n'est en cours d'exécution, recherchez un autre fichier LOCK sur le serveur. Supprimez le fichier manuellement, puis relancez la synchronisation.

Si la synchronisation était incomplète (par exemple, tous les membres d'un groupe n'ont pas été synchronisés), il se peut que l'API Directory rencontre un problème. Pour vérifier si le problème concerne une API et non le produit GCDS, appelez manuellement l'API Directory et examinez les résultats. Pour appeler l'API manuellement, choisissez l'une des deux options suivantes.

Option 1 : Utiliser la page de référence de l'API

1. Accédez à la présentation de la documentation de référence de l'API SDK Admin.
2. Sur la gauche, cliquez sur API Directory, puis, dans Ressources REST, accédez à la ressource REST que vous souhaitez interroger.
3. Sur la droite, cliquez sur la méthode que vous souhaitez essayer, puis sur Essayer.

   Si l'option Essayer ne s'affiche pas sur la page de référence de l'API, passez à l'option 2 (Utiliser OAuth 2.0 Playground).

4. Saisissez les identifiants d'administrateur que vous avez utilisés pour autoriser GCDS.

   Pour en savoir plus, consultez Définir les paramètres de votre domaine Google.

5. Passez en revue les informations pour vous assurer que l'API a répondu comme prévu.

Option 2 : Utiliser OAuth 2.0 Playground

1. Ouvrez OAuth 2.0 Playground.
2. Sélectionnez une option :
   • Sélectionnez un champ d'application dans la liste.
   • Copiez un champ d'application de la liste Authorization scopes (Champs d'application d'autorisation) sur la page de référence de l'API. Collez ensuite le champ d'application dans le champ Input your own scopes (Saisir vos propres champs d'application).
3. Cliquez sur Authorize APIs (Autoriser les API).
4. Saisissez les identifiants d'administrateur que vous avez utilisés pour autoriser GCDS.

   Pour en savoir plus, consultez Définir les paramètres de votre domaine Google.

5. Cliquez sur Exchange authorization code for tokens (Échanger le code d'autorisation contre des jetons).

   Si le processus aboutit, vous êtes redirigé vers l'Étape 3 : Configurez la requête API.

6. Fournissez les informations demandées.

   Astuce : Vous trouverez la plupart des informations sur la page Web de référence des méthodes API.

7. Cliquez sur Send the request (Envoyer la requête).
8. Passez en revue les informations pour vous assurer que l'API a répondu comme prévu.

Dans votre fichier de configuration XML, configurez l'option useDynamicMaxCacheLifetime. Elle permet de configurer GCDS de façon à conserver les données en cache pendant huit jours maximum et à procéder plus fréquemment à des effacements d'ensembles de données (de petite taille ou de taille moyenne) dans la mémoire cache. Cela réduit les risques d'augmentation du volume de données non actualisées dans celle-ci ou d'apparition de conflits entre anciennes et nouvelles données. Dans les configurations créées à l'aide de GCDS 3.2.1 et versions ultérieures, l'option useDynamicMaxCacheLifetime est automatique.

Remarque : Ces erreurs se produisent généralement lorsque des modifications sont effectuées directement dans le domaine Google. Si vous utilisez GCDS pour la synchronisation, évitez d'apporter des modifications directement dans votre domaine Google. Modifiez plutôt les comptes utilisateur, groupes et autres entités dans votre annuaire LDAP. Ensuite, synchronisez ces modifications avec votre domaine Google, à l'aide de GCDS.

Si vous rencontrez des erreurs liées à la mémoire, augmentez la taille des segments de mémoire de la machine virtuelle Java. Pour ce faire, modifiez les fichiers sync-cmd.vmoptions et config-manager.vmoptions dans le répertoire d'installation de GCDS. Les entrées pertinentes se présentent comme suit :

• -Xmx1000m (taille maximale des segments de mémoire allouée)
• -Xms64m (taille minimale des segments de mémoire allouée)

Modifiez les fichiers sync-cmd.vmoptions et config-manager.vmoptions afin que les modifications s'appliquent aux versions de sync-cmd et du gestionnaire de configuration.

Modifiez le nombre -Xmx pour augmenter la quantité de mémoire. La lettre "m" qui suit le nombre indique que la mémoire est mesurée en mégaoctets (Mo). La taille de mémoire idéale dépend de la mémoire disponible sur le serveur GCDS et de la quantité de mémoire dont GCDS a besoin pour effectuer une synchronisation. Vous devrez peut-être tester plusieurs valeurs avant de trouver celle qui convient. Pour en savoir plus sur la quantité de RAM disponible nécessaire pour exécuter GCDS, consultez Configuration système requise pour GCDS.

Il peut s'agir d'un problème de configuration, tel qu'une erreur de configuration d'une règle d'exclusion. Ce type d'erreur de configuration peut être masqué par la mise en cache dans GCDS. 

GCDS conserve les données de votre service Google (tel que Google Workspace ou Cloud Identity) en mémoire cache pendant huit jours maximum. Selon la taille des données mises en cache, GCDS peut vider le cache plus fréquemment. Toutefois, s'il n'est pas vidé, vos mises à jour peuvent ne pas être visibles pendant huit jours maximum. 

Imaginons par exemple que vous synchronisez vos données LDAP et créez un groupe pour votre service Google, tel que Google Workspace ou Cloud Identity. Vous créez ensuite une règle pour exclure ce groupe des synchronisations à venir. La règle d'exclusion est incorrectement configurée et elle échoue. Toutefois, la synchronisation suivante appelle les données mises en cache et le groupe reste dans votre service Google. Lorsque vous exécutez une nouvelle synchronisation avec le cache vide, l'erreur de configuration entraîne la suppression du groupe dans votre service Google.

Pour vider manuellement le cache :

• Exécutez une synchronisation à partir du gestionnaire de configuration et sélectionnez l'option de vidage du cache lors de l'exécution de cette opération.
• Exécutez une synchronisation à partir de la commande et utilisez l'argument -f pour forcer le vidage du cache.
• Modifiez le fichier XML pour définir la valeur maxCacheLifetime sur 0.

Important : Un vidage de cache forcé risque d'allonger considérablement le temps de synchronisation.

Si le message d'erreur 409: Entity already exists (Cette entité existe déjà) s'affiche, cela signifie que GCDS tente de créer des utilisateurs Google qui existent déjà. Si aucune erreur ne s'affiche lors des synchronisations suivantes, il est probable que le cache GCDS soit obsolète. Vous pouvez donc ignorer l'erreur sans risque.

Si le problème se produit à chaque synchronisation ou à quelques jours d'intervalle, les raisons les plus probables sont les suivantes :

• Une règle d'exclusion d'utilisateurs Google est trop générique : elle correspond à certains utilisateurs Google qui figurent également dans l'annuaire LDAP.
• Une requête est trop restrictive : elle ne correspond pas à certains utilisateurs Google qui figurent également dans l'annuaire LDAP.

Ces deux scénarios peuvent amener GCDS à ignorer les utilisateurs Google existants. Si ces utilisateurs figurent dans les résultats de la règle de recherche d'utilisateurs LDAP, GCDS tente de les créer dans votre compte Google.

Pour résoudre le problème, modifiez la règle d'exclusion ou la requête de recherche. Si vous souhaitez que GCDS ignore complètement les utilisateurs de votre annuaire LDAP, ajustez votre règle de recherche d'utilisateurs LDAP ou créez une règle d'exclusion d'utilisateurs LDAP. Pour en savoir plus, consultez Exclure des données avec des règles d'exclusion et des requêtes.

Pour que les membres de groupes soient synchronisés séparément des résultats d'éventuelles règles de recherche d'utilisateurs, l'option INDEPENDENT_GROUP_SYNC est activée par défaut dans GCDS. Si vous synchronisez des groupes à l'aide des attributs member-reference (référence-membre), GCDS tente de résoudre l'adresse e-mail de chaque utilisateur figurant dans l'annuaire LDAP, quelles que soient les règles de recherche de comptes utilisateur.

Pour que les membres de groupes soient synchronisés uniquement sur la base des résultats des règles de recherche d'utilisateurs, supprimez INDEPENDENT_GROUP_SYNC de votre fichier de configuration XML. GCDS :

• résout les adresses des membres de groupes à l'aide des résultats des règles de recherche des comptes utilisateur ;
• ne synchronise en tant que membres de groupes que les comptes utilisateur inclus dans la synchronisation des utilisateurs ;
• exécute les règles de recherche d'utilisateurs, même si vous désactivez la synchronisation des comptes utilisateur dans Paramètres généraux

  (toutefois, les résultats ne sont pas synchronisés dans Google en tant que comptes utilisateur, mais en tant que membres de groupes, si les utilisateurs éligibles constituent également des membres de groupes).

En général, ce type de synchronisation n'est pas privilégié, en particulier si vous synchronisez des contacts partagés et que des membres de groupes constituent des contacts. Dans ce cas, les contacts ne sont pas synchronisés en tant que membres de groupes.

Ce problème se produit lorsque l'attribut LDAP configuré en tant qu'attribut "Group Name" (Nom de groupe) ne contient pas une adresse e-mail complète. Pour résoudre ce problème, vérifiez vos règles de recherche de groupes et assurez-vous que GCDS utilise une adresse e-mail complète pour le nom des groupes. Pour ce faire, utilisez une des méthodes suivantes :

• Remplacez l'attribut "Group Name" par un autre attribut LDAP ("Mail", par exemple) contenant une adresse e-mail complète pour chaque groupe.
• Cochez Replace domain names in LDAP email addresses (Remplacer le nom de domaine dans les adresses e-mail LDAP) dans les paramètres du domaine Google (Google Domain Settings) de sorte que votre attribut "Group Name Attribute" corresponde au nom des groupes côté Google.
• Ajoutez le nom de domaine à la suite du nom du groupe en spécifiant un suffixe de nom de groupe (Group Name Suffix) dans votre règle de recherche de groupes (Group Search Rule).

Assurez-vous d'avoir sélectionné MS Active Directory dans le champ du type de serveur de la section LDAP Configuration (Configuration LDAP).

Cette option est indiquée par SUPPRESS_DOMAIN dans le fichier XML. Elle est utilisée lorsque les adresses e-mail figurant dans l'annuaire LDAP sont associées à un autre domaine que votre domaine Google. Lorsque cette option est activée, GCDS retire de toutes les adresses e-mail qu'il lit la partie correspondant au nom de domaine.

Tous les traitements sont effectués sans le nom de domaine. Si vous utilisez des règles d'exclusion basées sur les adresses e-mail, vous devez ne prendre en compte que la partie locale de l'adresse pour la règle d'exclusion.

Par exemple, si Replace domain names in LDAP email addresses (Remplacer le nom de domaine dans les adresses e-mail LDAP) est désactivé et que vous créez une règle d'exclusion "Mot clé exact", vous devez saisir lucas@example.com en tant qu'adresse e-mail de l'utilisateur, afin que celle-ci corresponde à la règle d'exclusion. Si vous avez activé Remplacer les noms de domaine dans les adresses e-mail LDAP, utilisez lucas. Vous ne parviendrez pas à faire correspondre lucas@example.com, car @example.com est supprimé avant même que la comparaison ne soit effectuée.

Lorsque vous alimentez des groupes avec GCDS, vous ne pouvez pas imbriquer de groupes dynamiques dans des groupes statiques, et inversement. Dans GCDS, les requêtes destinées aux groupes statiques doivent être envoyées séparément de celles destinées aux groupes dynamiques. Toutefois, tous les groupes imbriqués doivent faire l'objet d'une même requête.

Il s'agit de trouver une manière de mettre en œuvre des groupes dynamiques en tant que groupes statiques. Vous pouvez automatiser une tâche qui envoie une requête à intervalles réguliers à chaque groupe dynamique afin de remplir les groupes statiques de l'annuaire. GCDS peut ainsi gérer les groupes statiques créés à partir des groupes dynamiques, au lieu de gérer ceux-ci.

Les résultats des requêtes LDAP dépendent des paramètres du gestionnaire de configuration et du serveur LDAP. Suivez les conseils de dépannage suivants si votre règle de recherche LDAP renvoie un résultat inattendu. Vérifiez les points suivants :

• La requête LDAP est correctement configurée dans le gestionnaire de configuration : lorsque vous configurez une règle de recherche, cliquez sur Test LDAP Query (Tester la requête LDAP) pour la vérifier. Pour en savoir plus, consultez Utiliser des règles de recherche LDAP pour synchroniser des données.
• Les requêtes multiples ne sont pas contradictoires : vérifiez que vous n'avez pas configuré de règle de recherche ou d'exclusion modifiant le résultat d'une requête.
• L'utilisateur autorisé pour le serveur LDAP dispose des autorisations suffisantes : assurez-vous que l'administrateur utilisé pour authentifier le serveur LDAP peut utiliser la ligne de commande sur le même serveur. Exécutez la requête sur le serveur LDAP et vérifiez les résultats.

Le message d'erreur Impossible de créer le groupe peut s'afficher.Message : non autorisé à accéder à cette ressource/API dans les journaux GCDS. 

Pour résoudre le problème, vérifiez que l'attribut Active Directory (AD) contenant le domaine des adresses e-mail des utilisateurs et des groupes correspond au domaine utilisé par votre compte super-administrateur.

En principe, ce problème se produit si vous synchronisez des contacts partagés et que les règles de recherche ne sont pas correctement définies.

Vous pouvez synchroniser deux types d'objets pertinents avec GCDS :

• Profils utilisateur : comptes utilisateur de votre domaine Google associés à des informations supplémentaires, telles qu'un numéro de téléphone ou une adresse. Vous pouvez uniquement synchroniser le profil des comptes utilisateur qui existent dans votre domaine.
• Contacts partagés : contacts externes avec lesquels les utilisateurs de votre domaine sont en relation.

Pour résoudre ce problème, corrigez vos règles de recherche de contacts partagés pour exclure les utilisateurs de votre propre domaine. Lors de la prochaine synchronisation, GCDS essaiera de supprimer les contacts redondants. Vous devrez peut-être ajuster la limite de suppression des contacts partagés pour cette première synchronisation.

Dans certains cas, lorsque les utilisateurs planifient ou organisent des réunions, leur principal lieu de travail ne s'affiche pas dans Google Agenda.

Si vous rencontrez ce problème, assurez-vous que le type de lieu, ainsi que les attributs de la zone sont définis sur "bureau".

Si vous rencontrez des problèmes avec des résultats de recherche, vérifiez les points suivants :

• Le champ d'application de la règle. Vous devrez peut-être lui attribuer la valeur Sub-tree.
• La règle de recherche que vous utilisez doit être correcte.
• Les attributs utilisés doivent exister et être visibles.

Votre requête LDAP : vérifiez la requête sur votre serveur LDAP avec le même nom d'utilisateur administrateur configuré dans GCDS.

Pour en savoir plus, consultez Utiliser des règles de recherche LDAP pour synchroniser des données.

Il est possible que la taille de votre police de caractère soit trop grande pour l'écran. La boîte de dialogue n'accepte pas les polices larges ou extra larges. Modifiez la taille de votre police ou apportez les modifications directement dans votre fichier XML.