Dépannage de la synchronisation des utilisateurs
By Mirko Peters · · Updated
Résolvez un utilisateur qui ne se synchronise pas avec Microsoft Entra ID grâce à des vérifications pas à pas portant sur la source d’identité, le périmètre, les attributs, les connecteurs et l’état de la synchronisation.
Automatically translated with AI from the original post. Read the English original

Si vous êtes arrivé ici, vous êtes probablement aux prises avec le problème, bien connu, des comptes utilisateurs qui n’apparaissent pas dans le cloud Microsoft. Qu’il s’agisse d’un utilisateur absent de Microsoft Entra ID, d’une synchronisation AD hybride incomplète ou d’un compte isolé qui refuse obstinément de se synchroniser, vous êtes au bon endroit. Ces situations sont une véritable source de maux de tête pour quiconque administre Microsoft 365, Azure ou des environnements d’identité hybrides.
Ce guide passe en revue les échecs de synchronisation les plus courants : synchronisations lentes, utilisateurs qui disparaissent ou apparaissent en double, erreurs « introuvable » et messages d’état peu explicites. Vous disposerez d’une méthode couvrant aussi bien les bases que les scénarios avancés, de l’échec d’installation de l’agent d’annuaire aux conflits complexes de correspondance d’objets. Nous passerons en revue tous les points de contrôle essentiels, les journaux et les outils nécessaires, et expliquerons pourquoi une démarche méthodique, pas à pas, est indispensable pour démêler les problèmes de synchronisation des utilisateurs.
Vous trouverez ici des instructions claires, des explications sur le fonctionnement sous-jacent de la synchronisation, des stratégies d’intervention et la manière de valider votre correction. Nous supposons que vous maîtrisez Active Directory, Windows Server et les portails d’administration Microsoft, mais nul besoin d’être un expert hors pair pour suivre. Prenez votre casquette d’administrateur : remettons ces utilisateurs là où ils doivent être, c’est-à-dire synchronisés.
Diagnostiquer les échecs de synchronisation cloud dans les intégrations locales de Microsoft Entra
La synchronisation des utilisateurs de votre Active Directory local vers Microsoft Entra ID est essentielle pour garder à jour l’identité et les accès à travers les services cloud. Ce processus repose sur Microsoft Entra Connect, un pont qui copie les modifications de votre environnement vers le cloud. Lorsque ce pont vacille, voire s’effondre, ce sont les utilisateurs et les organisations qui en subissent les conséquences, sous forme de connexions défaillantes ou de comptes manquants.
Au fond, une intégration réussie repose sur une architecture solide, des prérequis corrects et des flux de synchronisation prévisibles. Une simple erreur de configuration, une règle de pare-feu oubliée ou une autorisation de compte de service omise peut déclencher une longue recherche d’un utilisateur ou d’un groupe manquant. C’est pourquoi il est crucial de comprendre le tableau d’ensemble avant de plonger dans les détails : le passage de l’local au cloud, les tunnels réseau impliqués et les dépendances entre services.
Cette section pose le décor : elle explique ce qui fait fonctionner la synchronisation hybride et les erreurs les plus fréquentes des équipes informatiques, en particulier lorsque de nouvelles exigences ou des changements d’environnement les prennent au dépourvu. Comprendre la logique de chaque élément rendra chaque future session de dépannage moins obscure et nettement plus rapide.
Comment les objets locaux de Microsoft Entra se synchronisent avec le cloud
Dans les configurations de Microsoft Entra Connect, les objets AD locaux, comme les utilisateurs et les groupes, sont mis en correspondance avec le cloud à l’aide d’un ensemble d’attributs uniques. Le plus important d’entre eux est l’ID immuable, généré à partir de l’objectGUID de votre annuaire local et utilisé comme critère de correspondance définitif dans Microsoft Entra ID.
Lorsqu’un objet est créé ou modifié, Entra Connect récupère les données, applique les règles de synchronisation ou les mappages d’attributs, puis décide s’il faut créer, mettre à jour ou lier l’objet correspondant dans le cloud. Cela garantit une identité cohérente pour chaque utilisateur, dans tous les environnements, à condition que les noms, les GUID et la logique de correspondance soient correctement configurés. La plupart des incohérences et des blocages de synchronisation proviennent d’un mauvais alignement des attributs ou d’une confusion quant à l’objet qui « possède » l’identité dans les scénarios hybrides.
Vérifier les ports et les URL d’accès pour la synchronisation cloud Microsoft
- Vérifiez les ports TCP sortants : assurez-vous que votre serveur de synchronisation peut se connecter aux principaux services Microsoft. En général, les ports TCP 80 (HTTP) et 443 (HTTPS), et parfois 8080, doivent être ouverts pour le trafic sortant.
- Validez l’accès aux URL requises : Microsoft Entra Connect doit pouvoir atteindre des points de terminaison tels que login.microsoftonline.com, graph.windows.net et *.servicebus.windows.net. Vous trouverez la liste complète et à jour des URL requises dans la documentation Microsoft.
- Testez avec PowerShell ou un navigateur : utilisez des outils comme Test-NetConnection, curl ou même un navigateur pour confirmer que les points de terminaison répondent. Des connexions bloquées peuvent révéler des problèmes de DNS, de pare-feu ou de proxy.
- Examinez les journaux du pare-feu et du proxy : vérifiez qu’aucune interception TLS/SSL silencieuse ni aucun problème d’authentification au proxy n’interrompt votre trafic sortant, en particulier dans les environnements d’entreprise très verrouillés.
Vérifier l’état des services pour les environnements de synchronisation hybrides
Pour que la synchronisation reste fluide, tous les services critiques, à la fois sur votre serveur Microsoft Entra Connect et dans le cloud, doivent être opérationnels et en cours d’exécution. Sur site, cela implique de vérifier le service de synchronisation Microsoft Entra Connect via services.msc ou la console Gestionnaire de synchronisation. Surveillez les services arrêtés, désactivés ou en échec, car ils bloquent souvent la synchronisation complètement.
Côté cloud, consultez le tableau de bord d’état des services Microsoft pour repérer les rapports d’incident susceptibles d’affecter la synchronisation. Les journaux de service, les alertes et les messages d’état vous indiquent si des mises à jour, des interruptions ou des problèmes transitoires perturbent la connectivité de l’identité hybride. Identifier rapidement l’état du service vous permet d’écarter les causes environnementales au profit des problèmes de configuration spécifiques.
Résolution des problèmes liés à l’agent et à la configuration du serveur de synchronisation
Bien des choses peuvent mal tourner avant même qu’un seul objet utilisateur ne quitte votre serveur, surtout lors du déploiement initial ou des mises à niveau. Les agents de synchronisation ont besoin des bonnes autorisations, des prérequis logiciels et d’un accès réseau adéquat. Mais les environnements réels sont complexes : les stratégies de groupe peuvent bloquer l’exécution, un antivirus peut empêcher certaines étapes d’installation, ou les droits d’administrateur peuvent tout simplement faire défaut.
Cette section explique pourquoi les incidents côté agent sont si fréquents. Des installations défaillantes aux arrêts inattendus des services, bon nombre des problèmes récurrents trouvent leur origine dans la configuration de l’agent de synchronisation et dans la manière dont il est maintenu en bon état sur son hôte Windows Server. Des mises à jour ratées, des dépendances orphelines ou une maintenance négligée peuvent tous bloquer la synchronisation et désynchroniser vos annuaires utilisateurs.
Avant d’incriminer le cloud, il est utile de vérifier directement le fonctionnement de l’agent en local. Les sections suivantes vous guideront à travers des contrôles rapides et des correctifs robustes, afin de vous assurer que votre serveur de synchronisation remplit correctement son rôle avant de diagnostiquer les problèmes côté cloud.
Problèmes courants d’installation de l’agent et étapes de configuration du serveur
- Autorisations insuffisantes lors de la configuration : l’une des principales causes d’échec d’installation de l’agent est l’absence d’exécution en tant qu’administrateur local ou le manque de droits délégués dans Active Directory. Vérifiez systématiquement les autorisations avant de lancer le programme d’installation.
- Mauvaise configuration du compte de service : le service de synchronisation a besoin d’un compte dédié disposant de droits spécifiques sur l’annuaire et sur le serveur local. Un compte mal délimité ou l’expiration des mots de passe entraîne des erreurs de démarrage et des défaillances à l’exécution.
- Problèmes de confiance des certificats et de TLS/SSL : les environnements hybrides, en particulier ceux soumis à des contrôles de sécurité stricts, rencontrent souvent des difficultés liées à des autorités racines (CA racines) absentes ou expirées. Il en résulte des échecs silencieux de négociation TLS entre l’agent et le cloud. Vérifiez que le magasin de certificats Windows contient toutes les autorités racines de confiance nécessaires.
- Système d’exploitation et prérequis obsolètes : exécuter Microsoft Entra Connect sur des versions de Windows Server non prises en charge ou non corrigées, ou ne pas disposer des dépendances .NET Framework requises, est un problème récurrent. Vérifiez toujours la dernière version de Windows Server prise en charge et les mises à jour des prérequis avant toute installation ou mise à niveau.
- Logiciels en conflit ou stratégies GPO : la protection des terminaux, les pare-feux ou les stratégies de groupe restrictives peuvent interférer avec le démarrage et le fonctionnement de l’agent. Examinez les journaux des logiciels de sécurité et les paramètres de stratégie de groupe si les installations échouent de manière répétée ou si les services plantent sans message d’erreur clair.
Surveiller l’état de synchronisation des objets et effectuer des étapes de synchronisation delta
- Afficher l’état de la synchronisation : ouvrez le Gestionnaire de synchronisation sur votre serveur Microsoft Entra Connect. Consultez l’onglet « Opérations » pour les cycles de synchronisation récents, les erreurs et le nombre d’objets importés et exportés.
- Lancer une synchronisation delta manuelle : utilisez PowerShell sur le serveur de synchronisation : Start-ADSyncSyncCycle -PolicyType Delta. Cette commande ne synchronise que les modifications récentes, ce qui réduit le temps d’attente par rapport à une synchronisation complète.
- Vérifier les résultats de la synchronisation : une fois le cycle terminé, examinez la liste « Opérations » et les journaux des événements pour repérer les nouvelles erreurs. Confirmez que les modifications apportées aux utilisateurs, aux groupes ou aux attributs sont bien répercutées dans le cloud en consultant le Centre d’administration Microsoft Entra.
- Interpréter les messages d’échec : recherchez les détails des échecs dans les journaux du service de synchronisation ou dans la sortie PowerShell, notamment les utilisateurs non appariés, les refus d’autorisation ou les conflits d’attributs qui expliquent les synchronisations manquées.
Analyse des problèmes de synchronisation des objets et des erreurs d’appariement
Tous les problèmes de synchronisation ne sont pas dus à une défaillance générale du serveur ou du service : bien souvent, le coupable est un utilisateur ou un groupe précis présentant un conflit d’attributs, un doublon ou une incohérence entre ce qui existe en local et ce qui se trouve dans le cloud. Ce sont ces erreurs qui empêchent les administrateurs de dormir : un environnement de synchronisation parfaitement sain, mais un compte récalcitrant qui refuse obstinément d’apparaître, de fusionner ou de se mettre à jour correctement.
La cause première peut être aussi bien une faute de frappe dans un UPN qu’un ancien objet obsolète portant une adresse de messagerie ou un attribut proxy identique. L’identité hybride de Microsoft repose sur une danse appelée « matching » : la mise en correspondance souple, fondée sur les attributs principaux, et la mise en correspondance stricte, qui s’appuie sur l’ID immuable. Lorsque ces étapes échouent, les objets ne se synchronisent pas ou, pire, apparaissent en double ou sont orphelins.
Cette section vous permet de diagnostiquer les échecs de synchronisation au niveau de l’objet et vous aide à repérer les collisions de noms, les incohérences d’attributs et les erreurs d’autorisation, quelle que soit la profondeur à laquelle il faut creuser. Vous saurez ensuite comment faire correspondre et synchroniser correctement les comptes les plus insaisissables.
Diagnostic des objets locaux et de l’état de synchronisation des objets d’annuaire
- Vérifier les conflits d’attributs : utilisez des outils comme le Gestionnaire du service de synchronisation ou PowerShell (Get-ADUser, Get-MsolUser) pour comparer les attributs clés (UPN, adresse de messagerie, proxyAddresses) entre les comptes locaux et les comptes cloud.
- Examiner les journaux et l’état de la synchronisation : analysez les cycles de synchronisation récents à la recherche d’erreurs au niveau des utilisateurs, comme les « export errors » ou les avertissements « not synchronizing » dans l’onglet Opérations du service de synchronisation.
- Vérifier la logique de correspondance : confirmez que l’ID immuable de l’objet local (dérivé de objectGUID) correspond à celui présent dans Microsoft Entra ID ; une incohérence à ce niveau est un signal d’alerte pour les problèmes de synchronisation.
- Rechercher les doublons : exécutez des requêtes ou utilisez les filtres du portail pour repérer les objets existant uniquement dans le cloud qui peuvent bloquer la synchronisation locale parce qu’ils possèdent déjà les mêmes attributs.
Résolution des problèmes de mise en quarantaine du provisionnement et de l’autorisation du service d’annuaire
- Identifier les états de quarantaine : dans le Centre d’administration Microsoft Entra ou dans les journaux de synchronisation, recherchez les utilisateurs marqués comme « quarantined » en raison de problèmes de données ou d’autorisations.
- Examiner les autorisations sur l’annuaire : vérifiez que le compte de service utilisé par Entra Connect dispose des autorisations de lecture et d’écriture sur les objets et attributs Active Directory nécessaires.
- Rechercher les violations d’attributs : des utilisateurs peuvent être mis en quarantaine si leurs attributs ne respectent pas une stratégie (par exemple, formats non valides ou valeurs restreintes). Corrigez-les localement, puis relancez la synchronisation.
- Lever la quarantaine : une fois les causes profondes corrigées, retirez les utilisateurs de la quarantaine via le portail ou PowerShell, puis déclenchez une synchronisation delta pour rétablir le fonctionnement normal.
Dépannage de la synchronisation cloud à l’aide des journaux, des fichiers et du portail Microsoft
Lorsque les vérifications de base et les configurations ne suffisent pas à synchroniser les utilisateurs, l’étape suivante consiste à exploiter les riches outils de diagnostic à votre disposition. Entra Connect et ses services cloud génèrent une trace détaillée de ce qui s’est produit lors de chaque cycle de synchronisation : depuis les fichiers journaux de votre serveur Windows jusqu’aux messages d’erreur codés dans l’Observateur d’événements, en passant par les tableaux de bord d’état complets du Centre d’administration Microsoft Entra.
L’examen des bons journaux et l’utilisation des données en temps réel du portail vous permettent de passer des suppositions aux faits : vous verrez quelles erreurs se sont produites, quels objets sont restés bloqués et si le problème provient de votre déploiement ou du service Microsoft lui-même. Les outils d’automatisation et les rapports graphiques du portail peuvent même vous aider à repérer des tendances et à planifier des corrections futures pour éviter les pannes récurrentes.
Cette section présente les outils essentiels pour élucider les pertes de synchronisation silencieuses, les incohérences inexpliquées ou ces cas étranges où le service de synchronisation affiche « succès » alors qu’un utilisateur est toujours absent. Grâce à ces outils, même les problèmes d’identité hybride les plus complexes deviennent plus faciles à démêler et à prévenir.
Analyse des fichiers journaux et de la sortie de dépannage de la synchronisation cloud
- Journaux du Gestionnaire du service de synchronisation : situés dans C:\ProgramData\Microsoft\Azure AD Connect\Trace, ils détaillent chaque action de synchronisation ainsi que les codes d’erreur courants.
- Observateur d’événements Windows : consultez les journaux Application et Système à la recherche d’événements « Directory Synchronization » ou « Azure AD Connect » ; filtrez les avertissements ou erreurs.
- Journaux du portail Entra Connect Health : ils offrent une visualisation dans le cloud et un suivi historique des erreurs, idéal pour repérer les problèmes persistants ou intermittents.
- Sortie PowerShell : des scripts comme Get-ADSyncScheduler ou Get-ADSyncRunProfile affichent en temps réel le résultat de la synchronisation des objets ainsi que le détail des échecs.
Utiliser le portail Microsoft et le Centre d’automatisation pour surveiller la synchronisation
Le centre d’administration Microsoft Entra est votre guichet unique pour suivre la synchronisation en temps réel. Depuis la section « Identité », vous pouvez consulter l’état de santé de la synchronisation, suivre les erreurs au niveau des objets et examiner en détail les cycles de synchronisation récents. Le Centre d’automatisation vous permet de planifier des synchronisations, de configurer des alertes en cas d’échec et d’appliquer des corrections en un clic pour les problèmes courants.
Les ressources du centre d’aide en ligne, ainsi que les rapports Microsoft Graph, apportent du contexte aux problèmes persistants ou aux blocages au niveau des utilisateurs. Grâce à ces outils, le dépannage cesse d’être un jeu de devinettes pour devenir une démarche méthodique et fondée sur les données, qui vous permet de passer de la gestion des urgences à une gestion proactive des identités.
Confirmer la résolution de la synchronisation et les étapes de reporting
- Vérifier la présence de l’objet : recherchez l’utilisateur ou le groupe synchronisé dans l’AD local comme dans le portail cloud, afin de confirmer que l’objet a bien été transféré.
- Tester les connexions et les autorisations : tentez une connexion cloud avec l’utilisateur concerné pour vérifier que les identifiants et les stratégies d’accès fonctionnent désormais comme prévu.
- Examiner les journaux de synchronisation : vérifiez que les derniers cycles ne présentent aucune erreur et que les objets précédemment signalés affichent désormais « réussi » ou « terminé ».
- Documenter votre correction : consignez les étapes, les symptômes et les résultats du problème dans le journal d’incidents ou la base de connaissances de votre équipe, pour référence ultérieure.
- Planifier des synchronisations de suivi : mettez en place des contrôles réguliers ou une surveillance pour repérer les signes avant-coureurs si le même problème réapparaît.
Donner votre avis et apprendre des discussions de la communauté (21)
- Faire part de vos retours à Microsoft : utilisez le bouton de commentaires du portail d’administration Microsoft Entra ou de Microsoft Docs pour signaler des bogues ou demander de nouvelles fonctionnalités. Vous contribuez ainsi à améliorer les outils pour tous les administrateurs.
- Participer aux discussions des forums : rejoignez Microsoft Tech Community et les espaces dédiés à Entra ID pour poser vos questions et apporter des réponses. Au moins 21 autres administrateurs ont publié à propos de situations similaires : profitez de leur expérience et de leurs particularités.
- Partager votre cas dans les commentaires : ajoutez le détail de votre problème de synchronisation particulier aux articles de la base de connaissances, afin que les lecteurs à venir puissent s’appuyer sur des solutions éprouvées en conditions réelles.
- Exploiter les ressources du portail d’administration : consultez les guides de dépannage et les podcasts, comme cet épisode sur Entra ID et l’accès conditionnel, pour approfondir vos connaissances.
Comprendre les conflits d’ID immuable et de correspondance d’objets dans la synchronisation hybride
Nous abordons ici un sujet plus avancé : la correspondance des objets dans la synchronisation hybride n’est pas infaillible, et l’une des sources d’échec de synchronisation les plus délicates réside dans les incohérences d’ID immuable. Chaque utilisateur synchronisé depuis votre annuaire local possède dans le cloud un ID immuable unique, dérivé de son objectGUID d’origine. Si vous recréez ou migrez un utilisateur sans nettoyage approprié, le nouvel objet local reçoit un objectGUID neuf, alors que l’ancien ID immuable reste associé au compte cloud. Cette incohérence cachée bloque la synchronisation sans bruit ou génère des doublons.
À cela s’ajoute le fait que des objets utilisateur cloud uniquement subsistent parfois après d’anciennes migrations, bloquant les nouvelles tentatives de synchronisation depuis l’environnement local. Si vous n’identifiez pas et ne supprimez pas ces objets obsolètes ou orphelins, vos nouveaux utilisateurs n’apparaîtront pas, ou pire, une même personne se retrouvera avec deux comptes. La plupart des guides passent ces scénarios sous silence, pourtant ils font partie des plus gros casse-tête dans les déploiements d’identité réels.
Cette section lève le voile sur les raisons précises de l’apparition des conflits d’ID immuable et sur la manière de les isoler et de les résoudre pas à pas. Si les solutions simples n’ont pas fonctionné et que vous soupçonnez une incohérence d’identité, ces sous-sections sont indispensables dans votre boîte à outils.
Analyse des causes profondes des incohérences d’ID immuable lors de la réapprovisionnement des utilisateurs
Les incohérences d’ID immuable surviennent lorsqu’un utilisateur local est supprimé puis recréé sans que l’objet cloud n’ait été préalablement retiré ou mis à jour. Le nouvel utilisateur local peut avoir le même UPN ou la même adresse e-mail, mais un objectGUID différent : l’ID immuable généré ne correspond donc plus à celui présent dans Microsoft Entra ID. Il en résulte une synchronisation qui échoue silencieusement ou génère des erreurs de correspondance, et un compte orphelin ou dupliqué dans le cloud.
Pour résoudre ce problème, les administrateurs doivent identifier l’objet cloud en conflit, puis soit le faire correspondre de manière définitive au nouvel utilisateur local en mettant à jour son ID immuable (Immutable ID), soit supprimer l’objet cloud obsolète avant une nouvelle synchronisation. Ce processus est essentiel lors de la migration, de la restauration ou du reprovisionnement d’utilisateurs, car il garantit une transition fluide et évite les blocages invisibles au niveau de l’annuaire.
Détecter et résoudre les doublons d’objets utilisateurs entre l’environnement local et le cloud
- Identifier les utilisateurs cloud obsolètes : utilisez le filtrage du portail et PowerShell (Get-MsolUser -All | Where-Object {$_.LastDirSyncTime -eq $null}) pour repérer les objets utilisateurs qui n’ont jamais été synchronisés depuis l’environnement local.
- Vérifier les conflits d’attributs : comparez les attributs principaux, comme le UPN et l’adresse e-mail, entre les comptes cloud uniquement et les comptes locaux afin de repérer les chevauchements.
- Supprimer ou fusionner les doublons : supprimez ou fusionnez l’objet cloud uniquement via le portail ou PowerShell avant de relancer la synchronisation depuis l’environnement local. Cela lève le blocage et permet à l’objet visé d’apparaître.
- Resynchroniser l’utilisateur local : déclenchez une synchronisation delta et vérifiez que le nouvel objet apparaît dans le cloud avec les attributs corrects et l’ID immuable.
- Documenter le nettoyage : consignez l’ensemble des modifications et des étapes de résolution afin d’éviter toute confusion et d’empêcher le retour du problème lors de futures migrations ou réorganisations.
À écouter également
Si vous vous intéressez à l’utilisateur qui ne se synchronise pas avec Microsoft Entra ID, ces épisodes apportent un éclairage pratique sur la sécurité des identités, la gouvernance et la fiabilité des opérations Microsoft 365.
- Conditional Access – Simply Explained — Comprenez comment l’identité, l’appareil, la localisation et les signaux de risque influencent les décisions d’accès.
- Privileged Identity Management – Simply Explained — Découvrez comment les privilèges just-in-time et les workflows d’approbation réduisent l’exposition administrative.
- Microsoft Defender XDR – Simply Explained — Reliez les signaux d’identité à la détection, à l’investigation et à la réponse aux incidents.
- Microsoft Teams Governance – Simply Explained — Découvrez comment une responsabilité claire et des règles de cycle de vie rendent la collaboration sécurisée durable.
Ces épisodes vous aident à traduire les étapes techniques dans une stratégie plus large d’identité et de gouvernance.