Synchroniser un AD .local avec Microsoft Entra ID sans doublons (UPN, Cloud Sync vs Connect)

Vous devez synchroniser un Active Directory en .local avec Microsoft Entra ID sans générer de doublons ? Voici un guide opérationnel et éprouvé (UPN, sourceAnchor, soft/hard‑match, choix Cloud Sync vs Connect) pour réussir la migration de vos utilisateurs/groupes et préparer Power BI côté cloud.

Sommaire

Vue d’ensemble de la question

Objectif : mettre en place une synchronisation continue des utilisateurs et groupes entre l’AD local et Microsoft Entra ID (ex‑Azure AD), dans le cadre d’une migration Power BI vers le cloud.

Contraintes et symptômes :

Suffixe UPN on‑prem en .local (non routable) ; des comptes existent déjà dans le cloud (suffixe onmicrosoft.com).
Tests avec Entra Connect Sync et Cloud Sync ayant produit des doublons.
Crainte d’impacts sur les systèmes existants en cas de changement d’UPN.

Réponse & solutions

Ce qu’il faut décider avant tout

Domaine routable & UPN

Microsoft Entra ID n’accepte pas un suffixe UPN non vérifié (.local). Ajoutez et vérifiez votre domaine public routable (ex. exemple.com) dans le tenant, puis utilisez‑le pour les UPN de connexion.
Si vous n’alignez pas l’UPN avec un domaine vérifié, Entra substitue un suffixe onmicrosoft.com, ce qui rend l’appariement plus difficile et augmente le risque de doublons.

Moteur de synchronisation (choisir un seul pour un même périmètre)

Microsoft Entra Cloud Sync (agent léger) couvre la majorité des scénarios « Utilisateurs/Groupes ». Il peut coexister avec Connect seulement si leurs périmètres d’objets n’ont aucun chevauchement.
Microsoft Entra Connect Sync reste indiqué pour certains besoins complexes (ex. périphériques Hybrid Join, writeback étendu, règles de transformation avancées). Ne laissez jamais les deux moteurs exporter les mêmes objets vers le même tenant.

Ancre d’identité (sourceAnchor / immutableId)

Utilisez mS‑DS‑ConsistencyGuid comme sourceAnchor recommandé ; il est plus robuste que objectGUID en cas de migrations AD. L’attribut cloud immutableId doit correspondre à cette valeur (encodée en base64).

Changer l’UPN : risques réels et bonnes pratiques

Changer l’UPN est recommandé lorsque l’adresse e‑mail principale change ou pour converger avec le domaine routable. Cela n’affecte pas la connexion Windows via DOMAINE\samAccountName.
Les impacts potentiels concernent surtout des applications qui utilisent le UPN comme identifiant (SaaS/LOB, profils JIT, app provisioning, appareils joints, OneDrive/Office clients, Authenticator). Gérez‑les via un plan de changement : pilote, communication, support, fenêtre de bascule, FAQ aux utilisateurs, vérification MFA, etc.
Si vous ne pouvez pas basculer l’UPN on‑prem, Microsoft Entra permet la connexion par e‑mail (Alternate login ID) ; considérez‑la comme un filet de sécurité, pas comme une stratégie permanente.

Procédure étape‑par‑étape (sans doublons)

Préparation

Vérifier le domaine public (exemple.com) dans le tenant Entra ID, puis l’assigner comme suffixe UPN de connexion.
Ajouter le suffixe UPN exemple.com dans « Active Directory Domains and Trusts » et préparer le basculement par lot des UPN des utilisateurs ciblés (commencez par une OU pilote).
Choisir un moteur : Cloud Sync ou Connect Sync. Désactivez l’autre sur le périmètre concerné (staging mode, filtrage OU, ou arrêt/agent) pour supprimer tout chevauchement.
Confirmer le sourceAnchor = mS‑DS‑ConsistencyGuid (Connect peut l’initialiser s’il est vide).

Alignement des identités pour l’appariement

Alignez au minimum l’UPN ou la Primary SMTP (ProxyAddresses : entrée SMTP:prenom.nom@exemple.com) entre AD local et Entra ID.
Activez (si besoin) la soft‑match sur UPN au niveau du tenant ; la soft‑match par SMTP fonctionne par défaut.
Pour les comptes déjà existants dans le cloud :
- Soft‑match : possible via SMTP (toujours) et via UPN si autorisée dans le tenant.
- Attention : pas de soft‑match pour un utilisateur cloud qui détient un rôle administrateur ; retirez les rôles, purgez l’éventuel doublon, puis relancez la synchro (ou procédez en hard‑match).

Migration pilote (sécurisée)

Définissez un périmètre restreint (OU/groupe), activez le staging mode si vous utilisez Connect, et exécutez une Full puis Delta sync pour valider l’appariement attendu.
Surveillez et corrigez les erreurs (ex. InvalidSoftMatch lorsqu’un immutableId est déjà renseigné côté cloud) : purge depuis la corbeille Entra ou hard‑match.

Rattrapage des cas particuliers

Hard‑match (si la soft‑match échoue ou pour les comptes admin) : définissez immutableId dans le compte cloud à la valeur base64 du mS‑DS‑ConsistencyGuid on‑prem, puis synchronisez.

Mise en production

Étendez progressivement le périmètre de synchronisation.
Surveillez les collisions d’attributs (userPrincipalName, ProxyAddresses) ; le moteur met en quarantaine l’attribut en conflit jusqu’à résolution.
Exploitez les rapports Connect Health / journaux Cloud Sync et un tableau de bord de conformité (voir section « Surveillance & observabilité »).

Tableau de décision : Cloud Sync vs Connect Sync

Critère	Cloud Sync (agent)	Connect Sync (serveur)
Portée principale	Utilisateurs & groupes, writeback moderne (sélectif)	Scénarios complexes (règles avancées, Hybrid Join)
Infra & maintenance	Léger ; agents multiples haute dispo	Serveur Windows dédié, SQL local (selon version)
Coexistence	Possible sans chevauchement d’objets	Possible sans chevauchement d’objets
Transformations	Jeu de règles courant	Jeu de règles très étendu (MA/Sync Rules)
Cas Power BI	OK pour utilisateurs & groupes	OK, et utile si besoins hybrides périphériques

Playbook anti‑doublons

Bloquez le chevauchement : un seul moteur exporte un objet donné.
Alignez UPN et/ou Primary SMTP avant d’activer la synchro.
Activez la soft‑match UPN si pertinent.
Traitez les comptes administrateurs avec un hard‑match (ou retrait temporaire des rôles).
Purgez les doublons cloud (corbeille) avant relance d’une Full/Delta sync.
Vérifiez et initialisez mS‑DS‑ConsistencyGuid côté AD si absent.

Erreurs fréquentes & remédiations

Message/Code	Cause probable	Correctif
InvalidSoftMatch	`immutableId` existe côté cloud et ne correspond pas	Purger l’objet cloud (y compris de la corbeille) ou aligner via hard‑match
AttributeValueMustBeUnique / DuplicateAttribute	Collision UPN ou ProxyAddresses déjà utilisé par un autre objet	Corriger la valeur côté on‑prem ou cloud, relancer la synchro
ObjectTypeMismatch	Même identifiant (SMTP/UPN) revendiqué par des objets de types différents	Renommer l’attribut conflit, nettoyer les objets orphelins
PermissionIssue / ExportError	Droits insuffisants de l’agent/compte de synchro	Ajuster les permissions, rejouer une Full sync

Mini‑checklist opérationnelle

Domaine exemple.com vérifié dans Entra ID.
Suffixe UPN exemple.com ajouté dans l’AD et UPN des utilisateurs basculés (au moins pour le pilote).
Un seul moteur de synchro exporte le périmètre (Cloud Sync ou Connect).
sourceAnchor validé : mS‑DS‑ConsistencyGuid.
UPN et/ou Primary SMTP alignés pour permettre la soft‑match ; soft‑match UPN activée si utile.
Aucun rôle admin sur les comptes cloud à fusionner (sinon hard‑match).

Scripts & astuces utiles (à adapter)

Ajouter un suffixe UPN et basculer un lot d’utilisateurs (OU pilote)

# 1) Ajouter le suffixe UPN au niveau forêt
Set-ADForest -Identity (Get-ADForest).Name -UPNSuffixes @{add='exemple.com'}

# 2) Basculer l’UPN d’un lot pilote

Get-ADUser -SearchBase "OU=Pilote,DC=exemple,DC=local" -Filter \* -Properties SamAccountName |
ForEach-Object {
\$newUpn = "\$(\$*.SamAccountName)@exemple.com"
Set-ADUser \$* -UserPrincipalName \$newUpn
}

Vérifier/activer la soft‑match UPN (Microsoft Graph PowerShell)

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

\$dirSync = Get-MgDirectoryOnPremiseSynchronization
\$dirSync.Features.SoftMatchOnUpnEnabled  # Vérification

Update-MgDirectoryOnPremiseSynchronization `  -OnPremisesDirectorySynchronizationId $dirSync.Id`
-Features @{ SoftMatchOnUpnEnabled = "true" }   # Activation si besoin

Initialiser mS‑DS‑ConsistencyGuid si vide (à partir d’objectGUID)

# ATTENTION : à utiliser seulement si mS-DS-ConsistencyGuid est vide
Get-ADUser -Filter * -SearchBase "OU=Pilote,DC=exemple,DC=local" -Properties objectGuid,mS-DS-ConsistencyGuid |
  Where-Object { -not $_.'mS-DS-ConsistencyGuid' } |
  ForEach-Object {
    $bytes = $_.objectGuid.ToByteArray()
    Set-ADUser $_ -Add @{'mS-DS-ConsistencyGuid' = $bytes}
  }

Calculer l’ImmutableId (base64 du ConsistencyGuid) pour un hard‑match

# Récupérer ConsistencyGuid et calculer sa base64 (immutableId)
$user = Get-ADUser -Identity "jdupont" -Properties "mS-DS-ConsistencyGuid"
$immutableId = [System.Convert]::ToBase64String($user."mS-DS-ConsistencyGuid")
$immutableId
# Cette valeur doit être affectée au compte cloud cible (puis déclencher une synchro)

Diagnostiquer les collisions UPN/SMTP avant synchro

# Exporter UPN et Primary SMTP pour contrôle
Get-ADUser -SearchBase "OU=Pilote,DC=exemple,DC=local" -Filter * -Properties UserPrincipalName,ProxyAddresses |
  Select-Object SamAccountName,UserPrincipalName,
    @{n='PrimarySMTP';e={($_.ProxyAddresses | Where-Object {$_ -cmatch '^SMTP:'}) -replace '^SMTP:'}} |
  Export-Csv .\pilot-upn-smtp.csv -NoTypeInformation -Encoding UTF8

Surveillance & observabilité

Connect Health : surveillez la latence, les erreurs d’export, les collisions, la santé du moteur.
Cloud Sync : contrôlez l’état des agents, les jobs, et installez au moins deux agents par domaine pour la haute disponibilité.
Journaux : consignez les runs Full/Delta, les évènements d’erreurs, les objets mis en quarantaine.
KPIs : temps moyen d’appariement, taux de collision par 1 000 objets, temps de résolution moyen, nombre d’objets en quarantaine, SLA de synchro.

Plan de bascule UPN sans douleur

Pilote : 10–30 utilisateurs représentatifs (métiers, périphériques, licences M365, MFA).
Pré‑com : message clair (nouvelle méthode de connexion, impact éventuel sur OneDrive/Teams/Office, réauthentification possible).
Fenêtre : bascule UPN (scripté), Full sync, tests SSO/MFA, vérification d’accès aux applis critiques.
Support : trame de résolution rapide (réinitialiser session Office, réassocier Authenticator, vérifier ProxyAddresses).
Généralisation : lotir par entité/OU, répéter le cycle, surveiller KPIs.

Cas Power BI : groupes & autorisations

Les groupes de sécurité AD synchronisés vers Entra ID peuvent être réutilisés pour les rôles d’espaces de travail Power BI (Admin, Membre, Contributeur, Lecteur) et les autorisations de datasets.
Si des groupes existent déjà côté cloud, alignez les noms/alias pour éviter les conflits (mailNickname, ProxyAddresses).
Le Group writeback évolue : pour les scénarios modernes de writeback, privilégiez Cloud Sync si la fonctionnalité couvre votre besoin au moment de la mise en œuvre.

FAQ rapide

Dois‑je renommer mon domaine AD en .local ?
Non. Pour Microsoft Entra ID, il suffit d’utiliser un domaine routable vérifié pour l’UPN de connexion et, si nécessaire, d’activer la connexion par e‑mail.

Changer l’UPN cassera‑t‑il mes applications ?
Potentiellement celles qui stockent/liaisonnent sur le UPN ; d’où l’importance d’un pilote, d’un plan de com et de tests applicatifs (SSO, MFA, provisioning, profils).

Comment éviter les doublons à coup sûr ?
Un seul moteur par périmètre, UPN/Primary SMTP alignés, soft‑match UPN activée si utile, hard‑match pour les comptes admin, purge des objets cloud résiduels, mS‑DS‑ConsistencyGuid comme sourceAnchor.

Et si deux moteurs existent déjà ?
Placez l’un en staging (ou stoppez les exports), segmentez le périmètre (OU/filtrage), nettoyez les doublons, puis pérennisez un seul moteur pour chaque ensemble d’objets.

Modèle de plan de remédiation en cas de doublons

Inventaire : export des comptes cloud et on‑prem (UPN, ProxyAddresses, immutableId). Repérez les paires suspectes.
Décision : objet maître on‑prem (hybride) vs objet cloud (né natif). Déterminez la cible.
Nettoyage : si un objet cloud doit être remplacé, supprimez‑le, videz la corbeille et attendez la convergence.
Hard‑match : si nécessaire, posez l’immutableId base64 du mS‑DS‑ConsistencyGuid sur l’objet cloud cible.
Validation : lancez Full/Delta sync et vérifiez qu’aucun nouvel objet inattendu n’est créé.
Preuve : consignez les actions (horodatage, opérateur, objets, attributs affectés) pour audit.

Bonnes pratiques de sécurité & gouvernance

Principe du moindre privilège pour les comptes d’agent/moteur (lecture AD, écritures limitées si nécessaire pour mS‑DS‑ConsistencyGuid).
Isolation : dédiés serveurs/services pour Connect, mises à jour régulières, agents Cloud Sync redondants.
Chiffrement & secret management : mots de passe/clé d’agent protégés (coffre‑fort).
Change management : fiches de modifications, fenêtres, rollback prédéfini, contrôle post‑changement.

Exemple de runbook « zéro‑doublon »

Avant : freeze des créations manuelles cloud dans le périmètre pilote, audit des valeurs UPN/SMTP.
Pendant : bascule UPN, activation soft‑match UPN, Full sync en staging, contrôle des journaux.
Après : passage en production, surveillance des quarantaines, correction des collisions, communication utilisateur.

Réponses directes aux questions initiales

« Changer l’UPN peut‑il casser d’autres systèmes ? »
Oui, pour les applications qui utilisent le UPN comme identifiant. La démarche correcte est de planifier, conduire un pilote, communiquer et ajuster les liaisons applicatives. C’est néanmoins la bonne pratique de faire converger UPN et e‑mail pour le cloud.

« Comment procéder pas à pas ? »
Suivez la procédure : vérifier le domaine → ajouter le suffixe UPN → choisir un seul moteur → sourceAnchor = mS‑DS‑ConsistencyGuid → aligner UPN/SMTP → soft‑match (ou hard‑match) → pilote → généralisation.

Annexe : checklist Power BI

Confirmez que les groupes AD sont synchronisés et visibles dans Entra ID avant d’attribuer des rôles dans Power BI.
Préférez les groupes de sécurité pour la gestion des accès aux espaces de travail et aux jeux de données.
Évitez de maintenir des groupes « fantômes » uniquement cloud si un équivalent AD existe ; préférez l’alignement et la consolidation.

Conclusion

La clé d’une synchronisation AD .local vers Microsoft Entra ID sans doublons tient à trois décisions : un domaine routable pour les UPN, un seul moteur pour un même périmètre, et mS‑DS‑ConsistencyGuid comme ancre d’identité. Ajoutez à cela un pilotage rigoureux (soft/hard‑match, nettoyage des doublons, contrôles) et une communication utilisateur solide : vous obtiendrez une identité hybride propre et prête pour Power BI.