Résolution des problèmes de bout en bout des objets et attributs Microsoft Entra Connect
Cet article est destiné à établir une pratique courante pour résoudre les problèmes de synchronisation dans Microsoft Entra ID. Cette méthode s’applique aux situations dans lesquelles un objet ou un attribut ne se synchronise pas avec Azure Active AD et n’affiche aucune erreur sur le moteur de synchronisation, dans les journaux de la visionneuse d’applications ou dans les journaux Microsoft Entra. Il est facile de se perdre dans les détails s’il n’y a pas d’erreur évidente. Toutefois, en utilisant les meilleures pratiques, vous pouvez isoler le problème et fournir des insights pour Support Microsoft ingénieurs.
À mesure que vous appliquez cette méthode de résolution des problèmes à votre environnement, au fil du temps, vous pourrez effectuer les étapes suivantes :
- Résolvez les problèmes de la logique du moteur de synchronisation de bout en bout.
- Résolvez les problèmes de synchronisation plus efficacement.
- Identifiez les problèmes plus rapidement en prédisant l’étape dans laquelle elles se produisent.
- Identifiez le point de départ de l’examen des données.
- Déterminez la résolution optimale.
Les étapes fournies ici commencent au niveau local d’Active Directory et progressent vers l’ID Microsoft Entra. Ces étapes sont la direction la plus courante de la synchronisation. Toutefois, les mêmes principes s’appliquent à la direction inverse (par exemple, pour l’écriture différée d’attribut).
Prerequisites
Pour une meilleure compréhension de cet article, lisez d’abord les articles prérequis suivants pour mieux comprendre comment rechercher un objet dans différentes sources (AD, AD CS, MV, et ainsi de suite) et comprendre comment vérifier les connecteurs et la traçabilité d’un objet.
- Microsoft Entra Connect : comptes et autorisations
- Résoudre les problèmes d’un objet qui ne se synchronise pas avec l’ID Microsoft Entra
- Résoudre les problèmes de synchronisation d’objets avec Microsoft Entra Connect Sync
Mauvaises pratiques de résolution des problèmes
L’indicateur DirSyncEnabled dans Microsoft Entra ID contrôle si le locataire est prêt à accepter la synchronisation des objets à partir d’AD local. Nous avons vu de nombreux clients se trouver dans l’habitude de désactiver DirSync sur le locataire lors de la résolution des problèmes de synchronisation d’objets ou d’attributs. Il est facile de désactiver la synchronisation d’annuaires en exécutant l’applet de commande PowerShell suivante :
Set-MsolDirSyncEnabled -EnableDirSync $false "Please DON'T and keep reading!"
Note
Les modules Azure AD et MSOnline PowerShell sont dépréciés depuis le 30 mars 2024. Pour en savoir plus, lisez les informations de dépréciation. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.
Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.
Toutefois, cela peut être catastrophique, car il déclenche une opération back-end complexe et longue pour transférer SoA à partir d’Active Directory local vers Microsoft Entra ID / Exchange Online pour tous les objets synchronisés sur le locataire. Cette opération est nécessaire pour convertir chaque objet de DirSyncEnabled en cloud uniquement et nettoyer toutes les propriétés d’ombre synchronisées à partir d’AD local (par exemple, ShadowUserPrincipalName et ShadowProxyAddresses). En fonction de la taille du locataire, cette opération peut prendre plus de 72 heures. En outre, il n’est pas possible de prédire quand l’opération se termine. N’utilisez jamais cette méthode pour résoudre un problème de synchronisation, car cela entraîne des dommages supplémentaires et ne résout pas le problème. Vous ne pourrez plus activer DirSync jusqu’à ce que cette opération de désactivation soit terminée. En outre, après avoir réactivé DirSync, AADC doit à nouveau correspondre à tous les objets locaux avec des objets Microsoft Entra existants. Ce processus peut être perturbant.
Les seuls scénarios dans lesquels cette commande est prise en charge pour désactiver DirSync sont les suivants :
- Vous désaffectez votre serveur de synchronisation local et vous souhaitez continuer à gérer entièrement vos identités à partir du cloud au lieu d’identités hybrides.
- Vous disposez d’objets synchronisés dans le locataire que vous souhaitez conserver en tant que cloud uniquement dans Microsoft Entra ID et supprimer définitivement d’AD local.
- Vous utilisez actuellement un attribut personnalisé comme SourceAnchor dans AADC (par exemple, employeeId) et vous réinstallez AADC pour commencer à utiliser ms-Ds-Consistency-Guid/ObjectGuid comme nouvel attribut SourceAnchor (ou inversement).
- Vous disposez de certains scénarios qui impliquent des stratégies de migration de boîte aux lettres et de locataire risquées.
Dans certains cas, vous devrez peut-être arrêter temporairement la synchronisation ou contrôler manuellement les cycles de synchronisation AADC. Par exemple, vous devrez peut-être arrêter la synchronisation pour pouvoir exécuter une étape de synchronisation à la fois. Toutefois, au lieu de désactiver DirSync, vous pouvez arrêter uniquement le planificateur de synchronisation en exécutant l’applet de commande suivante :
Set-ADSyncScheduler -SyncCycleEnabled $false
Quand vous êtes prêt, démarrez manuellement un cycle de synchronisation en exécutant l’applet de commande suivante :
Start-ADSyncSyncCycle
Glossaire
Acronyme/abréviation | Nom/description |
---|---|
AADC | Microsoft Entra Connect |
AADCA | Compte du connecteur Microsoft Entra |
AADCS | Espace du connecteur Microsoft Entra |
AADCS :AttributeA | Attribut 'A' dans l’espace connecteur Microsoft Entra |
ACL | Listes de contrôle d’accès (également appelées autorisations ADDS) |
ADCA | Compte de connecteur AD |
ADCS | Espace du connecteur Active Directory |
AADCS :AttributeA | Attribut 'A' dans l’espace connecteur Active Directory |
ADDS ou AD | Services de domaine Active Directory |
CS | Espace du connecteur |
MV | Métaverse |
Compte MSOL | Compte du connecteur AD généré automatiquement (MSOL_########) |
MV:AttributeA | Attribut 'A' dans l’objet Metaverse |
SoA | Source de l’autorité |
Étape 1 : Synchronisation entre ADDS et ADCS
Objectif de l’étape 1
Déterminez si l’objet ou l’attribut est présent et cohérent dans ADCS. Si vous pouvez localiser l’objet dans ADCS et que tous les attributs ont les valeurs attendues, accédez à l’étape 2.
Description de l’étape 1
La synchronisation entre ADDS et ADCS se produit à l’étape d’importation et est le moment où AADC lit à partir du répertoire source et stocke les données dans la base de données. Autrement dit, lorsque les données sont intermédiaires dans l’espace connecteur. Lors d’une importation delta à partir d’AD, AADC demande toutes les nouvelles modifications qui se sont produites après un filigrane de répertoire donné. Cet appel est lancé par AADC à l’aide du contrôle DirSync des services d’annuaire sur le service de réplication Active Directory. Cette étape fournit le dernier filigrane comme dernière importation AD réussie et donne à AD la référence à un point dans le temps à partir de laquelle toutes les modifications (delta) doivent être récupérées. Une importation complète est différente, car AADC importera à partir d’AD toutes les données (dans l’étendue de synchronisation), puis marquera comme obsolètes (et supprimez) tous les objets qui se trouvent toujours dans ADCS, mais qui n’ont pas été importés à partir d’AD. Toutes les données entre AD et AADC sont transférées via LDAP et chiffrées par défaut.
Si la connexion avec AD réussit, mais que l’objet ou l’attribut n’est pas présent dans ADCS (en supposant que le domaine ou l’objet est dans l’étendue de synchronisation), le problème implique probablement des autorisations ADDS. L’ADCA nécessite des autorisations de lecture minimales sur l’objet dans AD afin d’importer des données dans ADCS. Par défaut, le compte MSOL dispose d’autorisations de lecture/écriture explicites pour toutes les propriétés utilisateur, groupe et ordinateur. Toutefois, cette situation peut encore poser problème si les conditions suivantes sont remplies :
- AADC utilise un ADCA personnalisé, mais il n’a pas été fourni suffisamment d’autorisations dans AD.
- Une unité d’organisation parente a bloqué l’héritage, ce qui empêche la propagation des autorisations à partir de la racine du domaine.
- L’objet ou l’attribut lui-même a bloqué l’héritage, ce qui empêche la propagation des autorisations.
- L’objet ou l’attribut dispose d’une autorisation de refus explicite qui empêche ADCA de la lire.
Résolution des problèmes d’Active Directory
Connectivité avec AD
Dans le Gestionnaire de service de synchronisation, l’étape « Importer à partir d’AD » indique quel contrôleur de domaine est contacté sous État de la connexion. Vous verrez probablement une erreur ici lorsqu’il existe un problème de connectivité qui affecte AD.
Si vous devez résoudre les problèmes de connectivité pour AD, en particulier si aucune erreur n’a été détectée dans le serveur Microsoft Entra Connect ou si vous êtes toujours en cours d’installation du produit, commencez par utiliser ADConnectivityTool.
Les problèmes de connexion à ADDS ont les causes suivantes :
- Informations d’identification AD non valides. Par exemple, l’ADCA a expiré ou le mot de passe a changé.
- Erreur « échec de la recherche », qui se produit lorsque le contrôle DirSync ne communique pas avec le service de réplication AD, généralement en raison d’une fragmentation de paquets réseau élevée.
- Erreur « no-start-ma », qui se produit lorsqu’il existe des problèmes de résolution de noms (DNS) dans AD.
- D’autres problèmes pouvant être causés par des problèmes de résolution de noms, des problèmes de routage réseau, des ports réseau bloqués, une fragmentation élevée des paquets réseau, aucun contrôleur de domaine accessible en écriture, et ainsi de suite. Dans ce cas, vous devrez probablement impliquer les services d’annuaire ou les équipes de support réseau pour vous aider à résoudre les problèmes.
Résumé de la résolution des problèmes
- Identifiez le contrôleur de domaine utilisé.
- Utilisez les contrôleurs de domaine préférés pour cibler le même contrôleur de domaine.
- Identifiez correctement l’ADCA.
- Utilisez ADConnectivityTool pour identifier le problème.
- Utilisez l’outil LDP pour essayer de lier le contrôleur de domaine à l’ADCA.
- Contactez les services d’annuaire ou une équipe de support réseau pour vous aider à résoudre les problèmes.
Exécuter l’utilitaire de résolution des problèmes de synchronisation
Après avoir résolu la connectivité AD, exécutez l’outil Résoudre les problèmes de synchronisation d’objets, car cela peut détecter les raisons les plus évidentes d’un objet ou d’un attribut de ne pas synchroniser.
Autorisations AD
Un manque d’autorisations AD peut affecter les deux directions de la synchronisation :
- Lorsque vous importez à partir de ADDS vers ADCS, un manque d’autorisations peut entraîner l’ignorer des objets ou des attributs afin qu’AADC ne puisse pas obtenir de mises à jour ADDS dans le flux d’importation. Cette erreur se produit parce que l’ADCA n’a pas suffisamment d’autorisations pour lire l’objet.
- Lorsque vous exportez d’ADCS vers ADDS, un manque d’autorisations génère une erreur d’exportation « problème d’autorisation ».
Pour vérifier les autorisations, ouvrez la fenêtre Propriétés d’un objet AD, sélectionnez Security>Advanced, puis examinez les ACL d’autorisation/refus de l’objet en sélectionnant le bouton Désactiver l’héritage (si l’héritage est activé). Vous pouvez trier le contenu de la colonne par type pour rechercher toutes les autorisations « refuser ». Les autorisations AD peuvent varier considérablement. Toutefois, par défaut, vous ne pouvez voir qu’un seul « Refuser la liste de contrôle d’accès » pour « Sous-système approuvé Exchange ». La plupart des autorisations sont marquées comme Autoriser.
Les autorisations par défaut suivantes sont les plus pertinentes :
Utilisateurs authentifiés
Tout le monde
Compte ADCA ou MSOL personnalisé
Accès compatible pré-Windows 2000
SELF
La meilleure façon de résoudre les problèmes d’autorisations consiste à utiliser la fonctionnalité « Accès effectif » dans la console Utilisateurs et ordinateurs AD. Cette fonctionnalité vérifie les autorisations effectives d’un compte donné (ADCA) sur l’objet ou l’attribut cible que vous souhaitez résoudre.
Important
La résolution des problèmes d’autorisations AD peut être difficile, car une modification des listes de contrôle d’accès ne prend pas effet immédiatement. Considérez toujours que ces modifications sont soumises à la réplication AD.
Par exemple :
- Vérifiez que vous apportez les modifications nécessaires directement au contrôleur de domaine le plus proche (consultez la section « Connectivité avec AD ») :
- Attendez que les réplications ADDS se produisent.
- Si possible, redémarrez le service ADSync pour effacer le cache.
Résumé de la résolution des problèmes
- Identifiez le contrôleur de domaine utilisé.
- Utilisez les contrôleurs de domaine préférés pour cibler le même contrôleur de domaine.
- Identifiez correctement l’ADCA.
- Utilisez l’outil Configurer les autorisations de compte de connecteur AD DS.
- Utilisez la fonctionnalité « Accès effectif » dans les utilisateurs et ordinateurs AD.
- Utilisez l’outil LDP pour établir une liaison avec le contrôleur de domaine qui a adCA et essayez de lire l’objet ou l’attribut défaillant.
- Ajoutez temporairement l’ADCA aux administrateurs d’entreprise ou aux administrateurs de domaine, puis redémarrez le service ADSync.
Important : n’utilisez pas cette solution.
- Après avoir vérifié le problème des autorisations, supprimez l’ADCA de tous les groupes hautement privilégiés et fournissez les autorisations AD requises directement à l’ADCA.
- Engagez les services d’annuaire ou une équipe de support réseau pour vous aider à résoudre la situation.
Réplications AD
Ce problème est moins susceptible d’affecter Microsoft Entra Connect, car il provoque des problèmes plus importants. Toutefois, lorsque Microsoft Entra Connect importe des données à partir d’un contrôleur de domaine à l’aide d’une réplication différée, il n’importe pas les dernières informations d’AD, ce qui provoque des problèmes de synchronisation dans lesquels un objet ou un attribut récemment créé ou modifié dans AD ne se synchronise pas avec l’ID Microsoft Entra, car il n’a pas été répliqué sur le contrôleur de domaine que Microsoft Entra Connect contacte. Pour vérifier qu’il s’agit du problème, vérifiez le contrôleur de domaine utilisé par AADC pour l’importation (voir « Connectivité à AD ») et utilisez la console Utilisateurs et ordinateurs AD pour vous connecter directement à ce serveur (voir Modifier le contrôleur de domaine dans l’image suivante). Vérifiez ensuite que les données sur ce serveur correspondent aux données les plus récentes et si elles sont cohérentes avec les données ADCS respectives. À ce stade, AADC génère une charge plus importante sur le contrôleur de domaine et la couche réseau.
Une autre approche consiste à utiliser l’outil RepAdmin pour vérifier les métadonnées de réplication de l’objet sur tous les contrôleurs de domaine, obtenir la valeur de tous les contrôleurs de domaine et vérifier l’état de réplication entre les contrôleurs de domaine :
Valeur d’attribut de tous les contrôleurs de domaine :
repadmin /showattr * "DC=contoso,DC=com" /subtree /filter:"sAMAccountName=User01" /attrs:pwdLastSet,UserPrincipalName
Métadonnées d’objet de toutes les contrôleurs de domaine :
repadmin /showobjmeta * "CN=username,DC=contoso,DC=com" > username-ObjMeta.txt
Résumé de la réplication AD
repadmin /replsummary
Résumé de la résolution des problèmes
- Identifiez le contrôleur de domaine utilisé.
- Comparez les données entre les contrôleurs de domaine.
- Analysez les résultats repAdmin.
- Contactez les services d’annuaire ou l’équipe de support réseau pour résoudre le problème.
Modifications de domaine et d’unité d’organisation, types d’objets ou attributs filtrés ou exclus dans ADDS Connector
La modification du filtrage de domaine ou d’unité d’organisation nécessite une importation complète
N’oubliez pas que même si le filtrage de domaine ou d’unité d’organisation est confirmé, les modifications apportées au filtrage de domaine ou d’unité d’organisation prennent effet uniquement après l’exécution d’une étape d’importation complète.
Filtrage d’attributs avec l’application Microsoft Entra et le filtrage d’attributs
Un scénario facile à manquer pour les attributs qui ne sont pas synchronisés est lorsque Microsoft Entra Connect est configuré avec la fonctionnalité de filtrage des attributs et de l’application Microsoft Entra. Pour vérifier si la fonctionnalité est activée et pour quels attributs, prenez un rapport de diagnostic général.
Type d’objet exclu dans la configuration du connecteur ADDS
Cette situation ne se produit pas aussi souvent pour les utilisateurs et les groupes. Toutefois, si tous les objets d’un type d’objet spécifique sont manquants dans ADCS, il peut être utile d’examiner les types d’objets activés dans la configuration du connecteur ADDS.
Vous pouvez utiliser l’applet de commande Get-ADSyncConnector pour récupérer les types d’objets activés sur le connecteur, comme indiqué dans l’image suivante. Voici les types d’objets qui doivent être activés par défaut :
(Get-ADSyncConnector | where Name -eq "Contoso.com").ObjectInclusionList
Voici les types d’objets qui doivent être activés par défaut :
Note
Le type d’objet publicFolder est présent uniquement lorsque la fonctionnalité Dossier public activé par courrier est activée.
Attribut exclu dans ADCS
De la même façon, si l’attribut est manquant pour tous les objets, vérifiez si l’attribut est sélectionné sur le connecteur AD.
Pour rechercher les attributs activés dans le connecteur ADDS, utilisez le Gestionnaire de synchronisation, comme indiqué dans l’image suivante, ou exécutez l’applet de commande PowerShell suivante :
(Get-ADSyncConnector | where Name -eq "Contoso.com").AttributeInclusionList
Note
L’inclusion ou l’exclusion de types d’objets ou d’attributs dans Synchronization Service Manager n’est pas prise en charge.
Résumé de la résolution des problèmes
- Vérifier la fonctionnalité de filtrage des attributs et de l’application Microsoft Entra
- Vérifiez que le type d’objet est inclus dans ADCS.
- Vérifiez que l’attribut est inclus dans ADCS.
- Exécutez une importation complète.
Ressources pour l’étape 1
Ressources principales :
Get-ADSyncConnectorAccount - Identifier le compte connecteur approprié utilisé par AADC
Identifier les problèmes de connectivité avec ADDS
Trace-ADSyncToolsADImport (ADSyncTools) - Données de trace importées à partir de ADDS
LDIFDE - Objet dump from ADDS pour comparer les données entre ADDS et ADCS
LDP - Tester la connectivité et les autorisations AD Bind pour lire l’objet dans le contexte de sécurité d’ADCA
DSACLS - Comparer et évaluer les autorisations ADDS
Définir des autorisations de fonctionnalité >AdSync< - Appliquer les autorisations AADC par défaut dans ADDS
RepAdmin - Vérifier les métadonnées d’objet AD et l’état de réplication AD
Étape 2 : Synchronisation entre ADCS et MV
Objectif de l’étape 2
Cette étape vérifie si l’objet ou l’attribut passe de CS à MV (en d’autres termes, si l’objet ou l’attribut est projeté vers la MV). À ce stade, assurez-vous que l’objet est présent ou que l’attribut est correct dans ADCS (couvert à l’étape 1), puis commencez à examiner les règles de synchronisation et la traçabilité de l’objet.
Description de l’étape 2
La synchronisation entre ADCS et MV se produit à l’étape de synchronisation delta/complète. À ce stade, AADC lit les données intermédiaires dans ADCS, traite toutes les règles de synchronisation et met à jour l’objet MV respectif. Cet objet MV contient des liens CS (ou connecteurs) pointant vers les objets CS qui contribuent à ses propriétés et à la traçabilité des règles de synchronisation appliquées à l’étape de synchronisation. Au cours de cette phase, AADC génère plus de charge sur les couches sql Server (ou LocalDB) et réseau.
Résolution des problèmes de gestion dynamique ADCS > pour les objets
Vérifier les règles de synchronisation entrantes pour l’approvisionnement
Un objet présent dans ADCS, mais manquant dans MV indique qu’il n’existe aucun filtre d’étendue sur l’une des règles de synchronisation d’approvisionnement appliquées à cet objet. Par conséquent, l’objet n’a pas été projeté sur MV. Ce problème peut se produire s’il existe des règles de synchronisation désactivées ou personnalisées.
Pour obtenir la liste des règles de synchronisation d’approvisionnement entrant, exécutez la commande suivante :
Get-ADSyncRule | where {$_.Name -like "In From AD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft
Vérifier la traçabilité de l’objet ADCS
Vous pouvez récupérer l’objet défaillant à partir de l’ADCS en recherchant sur « DN ou Anchor » dans « Search Connector Space ». Sous l’onglet Traçabilité , vous verrez probablement que l’objet est un Disconnector (aucun lien vers MV) et que la traçabilité est vide. Vérifiez également si l’objet a des erreurs, en cas d’onglet d’erreur de synchronisation.
Exécuter une préversion sur l’objet ADCS
Sélectionnez Preview>Generate Preview Commit Preview> pour voir si l’objet est projeté sur MV. Si c’est le cas, un cycle de synchronisation complet doit résoudre le problème pour les autres objets dans la même situation.
Exporter l’objet vers XML
Pour une analyse plus détaillée (ou pour une analyse hors connexion), vous pouvez collecter toutes les données de base de données associées à l’objet à l’aide de l’applet de commande Export-ADSyncObject . Ces informations exportées permettent de déterminer quelle règle filtre l’objet. En d’autres termes, le filtre d’étendue entrant dans les règles de synchronisation d’approvisionnement empêche l’objet d’être projeté sur la MV.
Voici quelques exemples de syntaxe Export-ADsyncObject :
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
Export-ADsyncObject -DistinguishedName 'CN=TestUser,OU=Sync,DC=Domain,DC=Contoso,DC=com' -ConnectorName 'Domain.Contoso.com'
Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose
Résumé de la résolution des problèmes (objets)
- Vérifiez les filtres d’étendue sur les règles d’approvisionnement entrantes « In From AD ».
- Créez un aperçu de l’objet.
- Exécutez un cycle de synchronisation complet.
- Exportez les données d’objet à l’aide du script Export-ADSyncObject .
Résolution des problèmes de gestion dynamique ADCS > pour les attributs
Identifier les règles de synchronisation entrantes et les règles de transformation de l’attribut
Chaque attribut a son propre ensemble de règles de transformations qui sont responsables de diriger la valeur d’ADCS vers MV. La première étape consiste à identifier les règles de synchronisation qui contiennent la règle de transformation pour l’attribut que vous résolvez.
La meilleure façon d’identifier les règles de synchronisation qui ont une règle de transformation pour un attribut donné consiste à utiliser les fonctionnalités de filtrage intégrées de l’éditeur de règles de synchronisation.
Vérifier la traçabilité de l’objet ADCS
Chaque connecteur (ou lien) entre le CS et la MV aura une traçabilité qui contient des informations sur les règles de synchronisation appliquées à cet objet CS. L’étape précédente vous indique quel ensemble de règles de synchronisation entrantes (si les règles de synchronisation d’approvisionnement ou de jointure) doivent être présentes dans la traçabilité de l’objet pour transmettre la valeur correcte d’ADCS à MV. En examinant la traçabilité sur l’objet ADCS, vous pourrez déterminer si cette règle de synchronisation a été appliquée à l’objet.
S’il existe plusieurs connecteurs (plusieurs forêts AD) liés à l’objet MV, vous devrez peut-être examiner les propriétés de l’objet Métaverse pour déterminer le connecteur qui contribue à la valeur d’attribut à l’attribut que vous essayez de résoudre. Une fois que vous avez identifié le connecteur, examinez la traçabilité de cet objet ADCS.
Vérifier les filtres d’étendue sur la règle de synchronisation entrante
Si une règle de synchronisation est activée mais n’est pas présente dans la traçabilité de l’objet, l’objet doit être filtré par le filtre d’étendue de la règle de synchronisation. En vérifiant les filtres d’étendue de la règle de synchronisation, les données sur l’objet ADCS et si la règle de synchronisation est activée ou désactivée, vous devez être en mesure de déterminer pourquoi cette règle de synchronisation n’a pas été appliquée à l’objet ADCS.
Voici un exemple de filtre d’étendue problématique courant à partir d’une règle de synchronisation responsable de la synchronisation des propriétés Exchange. Si l’objet a une valeur null pour mailNickName, aucun des attributs Exchange dans les règles de transformation n’est acheminé vers l’ID Microsoft Entra.
Exécuter une préversion sur un objet ADCS
Si vous ne pouvez pas déterminer pourquoi la règle de synchronisation est manquante dans la traçabilité de l’objet ADCS, exécutez un aperçu à l’aide de Générer un aperçu et valider l’aperçu pour une synchronisation complète de l’objet. Si l’attribut est mis à jour dans la MV et a une préversion, un cycle de synchronisation complet doit résoudre le problème pour d’autres objets dans la même situation.
Exporter l’objet vers XML
Pour une analyse plus détaillée ou une analyse hors connexion, vous pouvez collecter toutes les données de base de données associées à l’objet à l’aide du script Export-ADSyncObject . Ces informations exportées peuvent vous aider à déterminer la règle de synchronisation ou la règle de transformation manquante sur l’objet qui empêche le projet de l’attribut vers la MV (voir les exemples Export-ADSyncObject plus haut dans cet article).
Résumé de la résolution des problèmes (pour les attributs)
- Identifiez les règles de synchronisation et les règles de transformation correctes responsables du flux de l’attribut vers la MV.
- Vérifiez la traçabilité de l’objet.
- Vérifiez si les règles de synchronisation ont été activées.
- Vérifiez les filtres d’étendue des règles de synchronisation manquantes dans la traçabilité de l’objet.
Résolution avancée des problèmes du pipeline de règle de synchronisation
Si vous devez déboguer davantage le moteur ADSync (également appelé MiiServer) en termes de traitement des règles de synchronisation, vous pouvez activer le suivi ETW sur le fichier .config (C :\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). Cette méthode génère un fichier texte détaillé complet qui montre tout le traitement des règles de synchronisation. Toutefois, il peut être difficile d’interpréter toutes les informations. Utilisez cette méthode comme dernier recours ou si elle est indiquée par Support Microsoft.
Ressources pour l’étape 2
- Interface utilisateur de Synchronization Service Manager
- Éditeur de règles de synchronisation
- Script Export-ADsyncObject
- Start-ADSyncSyncCycle -PolicyType Initial
- Suivi ETW syncRulesPipeline (miiserver.exe.config)
Étape 3 : Synchronisation entre MV et AADCS
Objectif pour l’étape 3
Cette étape vérifie si l’objet ou l’attribut passe de MV à AADCS. À ce stade, assurez-vous que l’objet est présent ou que l’attribut est correct dans ADCS et MV (décrit dans les étapes 1 et 2). Ensuite, examinez les règles de synchronisation et la traçabilité de l’objet. Cette étape est similaire à l’étape 2, dans laquelle la direction entrante d’ADCS à MV a été examinée. Toutefois, à ce stade, nous allons nous concentrer sur les règles de synchronisation sortante et l’attribut qui passe de MV à AADCS.
Description de l’étape 3
La synchronisation entre MV et AADCS se produit à l’étape de synchronisation delta/complète, lorsque AADC lit les données dans MV, traite toutes les règles de synchronisation et met à jour l’objet AADCS respectif. Cet objet MV contient des liens CS (également appelés connecteurs) qui pointent vers les objets CS qui contribuent à ses propriétés et à la traçabilité des règles de synchronisation appliquées à l’étape de synchronisation. À ce stade, AADC génère plus de charge sur SQL Server (ou localDB) et sur la couche réseau.
Résolution des problèmes de MV vers AADCS pour les objets
Vérifier les règles de synchronisation sortante pour l’approvisionnement
Un objet présent dans MV, mais manquant dans AADCS indique qu’il n’existe aucun filtre d’étendue sur l’une des règles de synchronisation d’approvisionnement appliquées à cet objet. Par exemple, consultez les règles de synchronisation « Out to Microsoft Entra ID » indiquées dans l’image suivante. Par conséquent, l’objet n’a pas été provisionné dans AADCS. Cette erreur peut se produire s’il existe des règles de synchronisation désactivées ou personnalisées.
Pour obtenir la liste des règles de synchronisation d’approvisionnement entrant, exécutez la commande suivante :
Get-ADSyncRule | where {$_.Name -like "Out to AAD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft
Vérifier la traçabilité de l’objet ADCS
Pour récupérer l’objet défaillant à partir de la MV, utilisez une recherche métaverse, puis examinez l’onglet Connecteurs. Sous cet onglet, vous pouvez déterminer si l’objet MV est lié à un objet AADCS. Vérifiez également si l’objet a des erreurs, si un onglet d’erreur de synchronisation est présent.
Si aucun connecteur AADCS n’est présent, l’objet est probablement défini sur cloudFiltered=True. Vous pouvez vérifier si l’objet est filtré dans le cloud en examinant les attributs MV pour lesquels la règle de synchronisation contribue à la valeur cloudFiltered .
Exécuter un aperçu sur un objet AADCS
Sélectionnez Aperçu>Générer la préversion>Valider un aperçu pour déterminer si l’objet se connecte à AADCS. Dans ce cas, un cycle de synchronisation complet doit résoudre le problème pour les autres objets dans la même situation.
Exporter l’objet vers XML
Pour une analyse plus détaillée ou une analyse hors connexion, vous pouvez collecter toutes les données de base de données associées à l’objet à l’aide du script Export-ADSyncObject . Ces informations exportées, ainsi que la configuration des règles de synchronisation (sortantes), peuvent vous aider à déterminer quelle règle filtre l’objet et à déterminer quel filtre d’étendue sortant dans les règles de synchronisation d’approvisionnement empêche l’objet de se connecter avec L’AADCS).
Voici quelques exemples de syntaxe Export-ADsyncObject :
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose
Export-ADsyncObject -DistinguishedName 'CN={2B4B574735713744676B53504C39424D4C72785247513D3D}' -ConnectorName 'Contoso.onmicrosoft.com - AAD'
Résumé de la résolution des problèmes pour les objets
- Vérifiez les filtres d’étendue des règles d’approvisionnement sortante « Out to Microsoft Entra ID ».
- Créez un aperçu de l’objet.
- Exécutez un cycle de synchronisation complet.
- Exportez les données d’objet à l’aide du script Export-ADSyncObject .
Résolution des problèmes de MV vers AADCS pour les attributs
Identifier les règles de synchronisation sortante et les règles de transformation de l’attribut
Chaque attribut a son propre ensemble de règles de transformation qui sont responsables du flux de la valeur de MV vers AADCS. Commencez par identifier les règles de synchronisation qui contiennent la règle de transformation de l’attribut que vous résolvez.
La meilleure façon d’identifier les règles de synchronisation qui ont une règle de transformation pour un attribut donné consiste à utiliser les fonctionnalités de filtrage intégrées de l’éditeur de règles de synchronisation.
Vérifier la traçabilité de l’objet ADCS
Chaque connecteur (ou lien) entre le CS et la MV aura une traçabilité qui contient des informations sur les règles de synchronisation appliquées à cet objet CS. L’étape précédente vous indique quel ensemble de règles de synchronisation sortantes (si les règles de synchronisation d’approvisionnement ou de jointure) doivent être présentes dans la traçabilité de l’objet pour transmettre la valeur correcte de MV à AADCS. En examinant la traçabilité sur l’objet AADCS, vous pouvez déterminer si cette règle de synchronisation a été appliquée à l’objet.
Vérifier les filtres d’étendue sur la règle de synchronisation sortante
Si une règle de synchronisation est activée, mais pas présente dans la traçabilité de l’objet, elle doit être filtrée par le filtre d’étendue de la règle de synchronisation. En vérifiant la présence des filtres d’étendue de la règle de synchronisation et les données sur l’objet MV, et si la règle de synchronisation est activée ou désactivée, vous devez être en mesure de déterminer pourquoi cette règle de synchronisation n’a pas été appliquée à l’objet AADCS.
Exécuter une préversion sur un objet AADCS
Si vous déterminez pourquoi la règle de synchronisation est manquante dans la traçabilité de l’objet ADCS, exécutez un aperçu qui utilise Générer un aperçu et valider l’aperçu pour une synchronisation complète de l’objet. Si l’attribut est mis à jour dans la MV en ayant une préversion, un cycle de synchronisation complet doit résoudre le problème pour d’autres objets dans la même situation.
Exporter l’objet vers XML
Pour une analyse plus détaillée ou une analyse hors connexion, vous pouvez collecter toutes les données de base de données associées à l’objet à l’aide du script « Export-ADSyncObject ». Ces informations exportées, ainsi que la configuration des règles de synchronisation (sortantes), peuvent vous aider à déterminer quelle règle de synchronisation ou règle de transformation est manquante dans l’objet qui empêche l’attribut de circuler vers AADCS (voir les exemples « Export-ADSyncObject » plus haut).
Résumé de la résolution des problèmes pour les attributs
- Identifiez les règles de synchronisation et les règles de transformation appropriées qui sont responsables du flux de l’attribut vers AADCS.
- Vérifiez la traçabilité de l’objet.
- Vérifiez que les règles de synchronisation sont activées.
- Vérifiez les filtres d’étendue des règles de synchronisation manquantes dans la traçabilité de l’objet.
Résoudre les problèmes liés au pipeline de règle de synchronisation
Si vous devez déboguer davantage le moteur ADSync (également appelé MiiServer) en termes de traitement des règles de synchronisation, vous pouvez activer le suivi ETW sur le fichier .config (C :\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). Cette méthode génère un fichier texte détaillé complet qui montre tout le traitement des règles de synchronisation. Toutefois, il peut être difficile d’interpréter toutes les informations. Utilisez cette méthode uniquement comme dernier recours ou si elle est indiquée par Support Microsoft.
Ressources
- Interface utilisateur de Synchronization Service Manager
- Éditeur de règles de synchronisation
- Script Export-ADsyncObject
- Start-ADSyncSyncCycle -PolicyType Initial
- Suivi ETW syncRulesPipeline (miiserver.exe.config)
Étape 4 : Synchronisation entre AADCS et AzureAD
Objectif pour l’étape 4
Cette étape compare l’objet AADCS à l’objet respectif approvisionné dans l’ID Microsoft Entra.
Description de l’étape 4
Plusieurs composants et processus impliqués dans l’importation et l’exportation de données vers et depuis Microsoft Entra ID peuvent entraîner les problèmes suivants :
- Connectivité à Internet
- Pare-feu internes et connectivité ISP (par exemple, trafic réseau bloqué)
- Passerelle Microsoft Entra devant le service web DirSync (également appelé point de terminaison AdminWebService)
- API de service web DirSync
- Service d’annuaire Microsoft Entra Core
Heureusement, les problèmes qui affectent ces composants génèrent généralement une erreur dans les journaux d’événements qui peuvent être suivis par Support Microsoft. Par conséquent, ces problèmes sont hors de portée pour cet article. Néanmoins, il existe encore des questions « silencieuses » qui peuvent être examinées.
Résolution des problèmes liés à AADCS
Plusieurs serveurs AADC actifs exportant vers Microsoft Entra ID
Dans un scénario courant dans lequel les objets dans Microsoft Entra ID retournent des valeurs d’attribut de retour et de retour, il existe plusieurs serveurs Microsoft Entra Connect actifs, et l’un de ces serveurs perd le contact avec l’AD local, mais est toujours connecté à Internet et peut exporter des données vers Microsoft Entra ID. Par conséquent, chaque fois que ce serveur « obsolète » importe une modification de l’ID Microsoft Entra sur un objet synchronisé effectué par l’autre serveur actif, le moteur de synchronisation rétablit cette modification en fonction des données AD obsolètes qui se trouve dans l’ADCS. Un symptôme typique dans ce scénario est que vous apportez une modification dans AD synchronisée avec l’ID Microsoft Entra, mais que la modification revient à la valeur d’origine quelques minutes plus tard (jusqu’à 30 minutes). Pour atténuer rapidement ce problème, revenez à tous les anciens serveurs ou machines virtuelles qui ont été désactivés et vérifiez si le service ADSync est toujours en cours d’exécution.
Attribut mobile avec DirSyncOverrides
Lorsque l’administrateur utilise le module MSOnline ou AzureAD PowerShell, ou si l’utilisateur accède au portail Office et met à jour l’attribut Mobile , le numéro de téléphone mis à jour est remplacé dans AzureAD malgré la synchronisation de l’objet à partir d’AD local (également appelé DirSyncEnabled).
Avec cette mise à jour, l’ID Microsoft Entra définit également un DirSyncOverrides sur l’objet pour indiquer que cet utilisateur a le numéro de téléphone mobile « remplacé » dans l’ID Microsoft Entra. À partir de ce stade, toute mise à jour de l’attribut mobile provenant d’un emplacement local est ignorée, car cet attribut ne sera plus géré par AD local.
Pour plus d’informations sur la fonctionnalité BypassDirSyncOverrides et sur la restauration de la synchronisation des attributs Mobile et autresMobile de Microsoft Entra ID vers Active Directory local, consultez Comment utiliser la fonctionnalité BypassDirSyncOverrides d’un locataire Microsoft Entra.
Les modifications UserPrincipalName ne sont pas mises à jour dans l’ID Microsoft Entra
Si l’attribut UserPrincipalName n’est pas mis à jour dans l’ID Microsoft Entra, tandis que d’autres attributs se synchronisent comme prévu, il est possible qu’une fonctionnalité nommée SynchronizeUpnForManagedUsers n’est pas activée sur le locataire. Ce scénario se produit fréquemment.
Avant l’ajout de cette fonctionnalité, toutes les mises à jour apportées à l’UPN provenant d’un emplacement local après l’approvisionnement de l’utilisateur dans l’ID Microsoft Entra et l’attribution d’une licence étaient ignorées en mode silencieux. Un administrateur doit utiliser MSOnline ou Azure AD PowerShell pour mettre à jour l’UPN directement dans l’ID Microsoft Entra. Une fois cette fonctionnalité mise à jour, toutes les mises à jour d’UPN sont transmises à Microsoft Entra, que l’utilisateur dispose d’une licence (gérée).
Note
Une fois activée, cette fonctionnalité ne peut pas être désactivée.
Les mises à jour UserPrincipalName fonctionnent si l’utilisateur n’est pas sous licence. Toutefois, sans la fonctionnalité SynchronizeUpnForManagedUsers , UserPrincipalName change une fois l’utilisateur approvisionné et reçoit une licence qui ne sera pas mise à jour dans l’ID Microsoft Entra. Notez que Microsoft ne désactive pas cette fonctionnalité pour le compte du client.
Caractères non valides et internes ProxyCalc
Les problèmes qui impliquent des caractères non valides qui ne produisent aucune erreur de synchronisation sont plus gênants dans les attributs UserPrincipalName et ProxyAddresses en raison de l’effet en cascade dans le traitement ProxyCalc qui ignorera silencieusement la valeur synchronisée à partir d’AD local. Cette situation se produit comme suit :
Le nom UserPrincipalName obtenu dans Microsoft Entra ID sera le MailNickName ou CommonName @ (at) domaine initial. Par exemple, au lieu de John.Smith@Contoso.com: UserPrincipalName dans Microsoft Entra ID peut devenir smithj@Contoso.onmicrosoft.com parce qu’il existe un caractère invisible dans la valeur UPN à partir d’AD local.
Si un ProxyAddress contient un caractère d’espace, ProxyCalc l’ignore et génère automatiquement une adresse e-mail basée sur MailNickName au niveau du domaine initial. Par exemple, « SMTP : John.Smith@Contoso.com» n’apparaît pas dans Microsoft Entra ID, car il contient un espace après le signe deux-points.
Un UserPrincipalName qui inclut un caractère d’espace ou un ProxyAddress qui inclut un caractère invisible provoque le même problème.
Pour résoudre les problèmes d’un caractère non valide dans UserPrincipalName ou ProxyAddress, examinez la valeur stockée dans l’AD local à partir d’un LDIFDE ou de PowerShell exporté vers un fichier. Une astuce simple pour détecter un caractère invisible consiste à copier le contenu du fichier exporté, puis à le coller dans une fenêtre PowerShell. Le caractère invisible sera remplacé par un point d’interrogation ( ?), comme illustré dans l’exemple suivant.
Attribut ThumbnailPhoto (KB4518417)
Il existe une idée fausse générale qu’après avoir synchronisé ThumbnailPhoto à partir d’AD pour la première fois, vous ne pouvez plus la mettre à jour, ce qui n’est que partiellement vrai.
En règle générale, l’ID MiniaturePhoto dans Microsoft Entra ID est continuellement mis à jour. Toutefois, un problème se produit si l’image mise à jour n’est plus récupérée à partir de Microsoft Entra ID par la charge de travail ou le partenaire respectif (par exemple, EXO ou SfBO). Ce problème provoque la fausse impression que l’image n’a pas été synchronisée entre AD local et Microsoft Entra ID.
Étapes de base pour résoudre les problèmes de ThumbnailPhoto
Vérifiez que l’image est correctement stockée dans AD et ne dépasse pas la limite de taille de 100 Ko.
Vérifiez l’image dans le portail des comptes ou utilisez Get-AzureADUserThumbnailPhoto , car ces méthodes lisent la MiniaturePhoto directement à partir de l’ID Microsoft Entra.
Si la miniature AD (ou AzureAD) a l’image correcte, mais n’est pas correcte sur d’autres services en ligne, les conditions suivantes peuvent s’appliquer :
- La boîte aux lettres de l’utilisateur contient une image HD et n’accepte pas les images à faible résolution de Microsoft Entra thumbnailPhoto. La solution consiste à mettre directement à jour l’image de boîte aux lettres de l’utilisateur.
- L’image de boîte aux lettres de l’utilisateur a été mise à jour correctement, mais vous voyez toujours l’image d’origine. La solution consiste à attendre au moins six heures pour voir l’image mise à jour dans le portail utilisateur Office 365 ou le Portail Azure.
Ressources supplémentaires
- Résolution des erreurs lors de la synchronisation
- Résoudre les problèmes de synchronisation d’objets avec Microsoft Entra Connect Sync
- Résoudre les problèmes d’un objet qui ne se synchronise pas avec l’ID Microsoft Entra
- Microsoft Entra Connect Single Object Sync
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.