Vous migrez Azure AD Connect v2.2.1.0 vers Microsoft Entra ID Connect v2.3.20.0 en mode « swing » ? Voici pourquoi l’attribut onPremisesObjectIdentifier apparaît dans le rapport d’export, comment valider l’impact réel et basculer sereinement en production.
Mise à jour d’Azure AD Connect vers Microsoft Entra ID Connect
Vue d’ensemble de la question
Un administrateur réalise une migration « swing » de Azure AD Connect v2.2.1.0 vers Microsoft Entra ID Connect v2.3.20.0 avec la séquence suivante :
- Installation d’un nouveau serveur en mode staging.
- Import de la configuration exportée du serveur actif.
- Génération d’un rapport d’export (pré‑export) pour anticiper les écritures côté Microsoft Entra ID.
Le rapport indique, pour chaque utilisateur, une mise à jour de l’attribut onPremisesObjectIdentifier (ancienne valeur vide → nouvelle valeur renseignée). D’où la crainte d’incohérences lorsque le nouveau serveur passera en mode actif.
Réponse & solution
| Point clé | Explications & actions recommandées |
|---|---|
| Pourquoi cette mise à jour ? | Depuis la branche 2.2.8.0, onPremisesObjectIdentifier figure dans les règles de synchronisation par défaut pour favoriser l’interopérabilité (notamment le provisioning de groupes AD via Cloud Sync). Votre ancien serveur ne le renseignait pas ; son ajout massif est attendu et s’affiche comme une action « add » dans le pré‑export. |
| Validation avant bascule | Confirmer que la seule modification massife porte bien sur cet attribut. Exécuter un cycle de synchro delta sur le serveur en staging (aucun export réel tant qu’il reste en staging). Contrôler l’absence d’erreurs dans Synchronization Service Manager et dans Connect Health. |
| Basculer les rôles | Passer l’ancien serveur en staging. Désactiver le staging sur le nouveau serveur pour le rendre actif. Surveiller les premiers cycles ; l’attribut sera écrit une seule fois, sans impact fonctionnel côté Entra ID. |
| Surveillance après mise en production | Suivre Microsoft Entra Connect Health et les cmdlets PowerShell Get-ADSyncRunProfile, Get-ADSyncConnectorRunStatus. Surveiller les alertes « Export Errors », « Large Object », « Synchronization Rule Errors ». |
| Plan de repli | Conserver l’ancien serveur en staging plusieurs jours ; en cas d’incident, repasser celui‑ci en actif. |
| Bonnes pratiques additionnelles | Sauvegarder les règles personnalisées avec Export-ADSyncServerConfiguration. Vérifier la compatibilité SQL (SQL Server 2019 ou version prise en charge). Forcer TLS 1.2 au niveau de l’OS (prérequis depuis la branche 2.2.x). |
À retenir
- Les mises à jour
onPremisesObjectIdentifiersont normales et n’entraînent pas de désynchronisation. - Si le rapport ne révèle aucune autre modification inattendue, vous pouvez poursuivre la bascule en toute confiance.
Comprendre onPremisesObjectIdentifier et ses implications
onPremisesObjectIdentifier stocke dans Microsoft Entra ID un identifiant stable et corrélable du compte local AD. Son écriture par Entra ID Connect n’altère pas les attributs on‑premises : c’est une donnée côté cloud utilisée par les mécanismes de corrélation (groupes, appartenance, scénarios multi‑connecteurs, coexistence avec Cloud Sync, etc.).
Concrètement, le premier export après l’activation du nouveau serveur ajoute la valeur pour tous les objets concernés. Il ne s’agit pas d’une remise à zéro des ancrages (sourceAnchor/ImmutableId) ni d’une modification de l’authentification (PHS/PTA/AD FS). La modification est idempotente : une fois l’attribut renseigné, les cycles suivants ne le réécrivent pas.
Différences avec les autres identifiants
| Identifiant | Portée | Rôle | Impact pendant la migration |
|---|---|---|---|
sourceAnchor / ImmutableId | On‑prem → Cloud | Clé de correspondance entre l’objet AD et Entra ID (souvent msDS-ConsistencyGuid). | Doit rester inchangé. Vérifier la cohérence entre les deux serveurs. |
onPremisesSecurityIdentifier (SID) | On‑prem → Cloud | Transport du SID du compte pour différents scénarios d’accès. | Ne change pas avec la bascule du moteur de synchro. |
onPremisesObjectIdentifier | Cloud | Identifiant corrélatif de l’objet on‑premises utilisé par des fonctionnalités récentes. | Ajout initial attendu lors du premier export. Pas d’effet sur les connexions ni les licences. |
Checklist de validation avant bascule (mode staging)
Effectuez les contrôles ci‑dessous tant que le nouveau serveur est en staging. En staging, l’orchestrateur réalise les imports et le métaverse, mais n’exporte pas vers Entra ID.
Vérifications rapides
- Règles de synchronisation : comparer les règles personnalisées (noms, précédence, étendues, transformations) avec l’éditeur de règles. Les personnalisations doivent porter une précédence supérieure aux règles par défaut si elles doivent s’appliquer en dernier.
- Connecteurs : mêmes domaines AD, mêmes UO filtrées, mêmes filtres d’inclusion/exclusion qu’en production.
- Options d’installation : PHS/PTA/SSO Seamless, writeback activés (groupes, appareils, mots de passe) si utilisés auparavant.
- Planification :
Get-ADSyncSchedulerdoit indiquerStagingMode : Truesur le nouveau serveur.
Commandes PowerShell utiles
# Sur le NOUVEAU serveur (staging)
# 1) Vérifier l'état du scheduler
Get-ADSyncScheduler
# 2) Lancer un cycle delta (aucun export en staging)
Start-ADSyncSyncCycle -PolicyType Delta
# 3) (Optionnel) Lancer un cycle initial pour tout rebalayer
Start-ADSyncSyncCycle -PolicyType Initial
# 4) Suivre l'exécution
Get-ADSyncRunProfile
Get-ADSyncConnectorRunStatus
# 5) Sauvegarder la configuration et les règles personnalisées
Export-ADSyncServerConfiguration -Path "C:\AADC-Backup" -NoPasswordAnalyser le pré‑export
- Dans Synchronization Service Manager (
miisclient.exe), ouvrir Operations et filtrer sur le connecteur Microsoft Entra. - Choisir un objet « Add » dans Pending Exports, puis Preview → Export pour visualiser la seule transformation attendue : l’ajout de
onPremisesObjectIdentifier. - Contrôler l’absence d’autres attributs non prévus (UPN, proxyAddresses, licences côté cloud, etc.).
Extraction ciblée des « adds » (option avancée)
Vous pouvez produire une photographie des exports prévus :
# Exporter la liste des changements en attente (vue synthétique)
$ops = Get-ADSyncRunProfile | Where-Object {$_.RunState -eq "Pending"}
# Selon vos pratiques internes, utilisez également l'outil csexport/CS logs
# pour exporter les opérations delta du connecteur Entra ID et les analyser.Procédure de bascule « swing » recommandée
- Ancien serveur → Staging : activer le mode staging pour stopper ses exports.
- Nouveau serveur → Actif : désactiver le staging. Surveiller immédiatement les jobs d’export côté Entra ID.
- Observation : vérifier que l’export contient essentiellement des « Add Attribute » sur
onPremisesObjectIdentifier. - Contrôles de cohérence :
- Nombre d’objets exportés cohérent (sanity check sur un échantillon).
- Aucun rename ou join douteux dans le métaverse.
- Aucune suppression massive (vérifier le seuil Export Deletion Threshold si configuré).
- Stabilisation : laisser tourner plusieurs cycles planifiés et valider l’absence de nouvelles écritures inattendues.
- Retrait du serveur historique (ultérieur) : une fois la stabilité confirmée, désinstaller ou conserver en staging selon votre politique de redondance.
Contrôles techniques approfondis
SourceAnchor et immutabilité
Assurez‑vous que les deux serveurs utilisent la même stratégie d’ancrage (recommandation actuelle : msDS-ConsistencyGuid). Un changement de sourceAnchor provoquerait des divergences majeures (nouveaux objets, pertes d’appartenance aux groupes). Comparez :
# Exemples de points de contrôle
(Get-ADSyncGlobalSettings).Parameters
Get-ADSyncRule | Select-Object Name, Precedence, Direction, ImmutableTag | Sort-Object PrecedenceRègles personnalisées
- Conservez les règles custom avec une précédence après les règles par défaut (numéros plus élevés) pour appliquer vos transformations métiers.
- Évitez de modifier une règle par défaut ; préférez la cloner pour sécuriser les mises à jour futures du produit.
Gestion des options de writeback
Si vous utilisiez le writeback (groupes, appareils, reset de mot de passe), vérifiez qu’il est réactivé à l’identique sur le nouveau serveur. Important : l’ajout de onPremisesObjectIdentifier est côté cloud uniquement ; il n’écrit rien dans AD.
Compatibilité plate‑forme
- TLS 1.2 forcé sur l’OS et les composants.
- SQL Server supporté (localDB ou instance dédiée : SQL 2019 ou version prise en charge).
- Service account (ADSync) correctement délégué (droits lecture AD, éventuels writeback) et mots de passe protégés.
Surveillance après mise en production
Dans les premières heures, concentrez la supervision sur les éléments suivants :
- Exports Entra ID : absence d’erreurs « Insufficient privileges », « ConstraintViolation », « Large Object » (attribut trop volumineux) ou « QuotaExceeded ».
- Connect Health : latence de synchro, erreurs de règles, performances (Imports/Sync/Exports), alertes de configuration.
- Expérience utilisateur : connexions, accès aux ressources, provisionnement de groupes et appartenance.
# Échantillon de contrôle continu
Get-ADSyncConnectorRunStatus | Format-Table ConnectorName, RunState, HResult
Get-ADSyncRunProfile | Sort-Object StartTime -Descending | Select-Object -First 10Plan de repli éprouvé
- Laisser l’ancien serveur en staging pendant plusieurs jours.
- En cas d’anomalie, reverser : activer l’ancien serveur (désactiver le staging), repasser le nouveau en staging.
- Documenter la cause (règle, connecteur, filtre) avant toute nouvelle tentative de bascule.
Bonnes pratiques de durcissement et d’exploitabilité
- Backups automatisés de la configuration (quotidien/hebdomadaire) avec
Export-ADSyncServerConfiguration. - Journalisation des changements (contrôle de source des scripts, Change Advisory Board, validation en pré‑prod).
- Échantillonnage des objets avant export (comptes sensibles, comptes de service, groupes dynamiques).
- Hygiène d’attributs : UPN uniques,
mail/proxyAddressessans doublon, normalisation des domaines. - Tests unitaires par cas d’usage (création utilisateur, move d’UO, changement d’UPN, appartenance à un grand groupe).
FAQ — Questions que vous vous posez probablement
Cette écriture massive peut‑elle casser SSO, PTA ou PHS ?
Non. onPremisesObjectIdentifier est orthogonal à l’authentification. Vos options d’authentification restent celles définies lors de l’installation (PHS/PTA/AD FS).
Y a‑t‑il un risque de duplication d’objets ?
Pas si le sourceAnchor est inchangé et si les règles de join restent identiques. L’ajout de onPremisesObjectIdentifier n’implique pas de nouveau join.
Un retour arrière supprime‑t‑il la valeur ajoutée ?
Non. Une fois l’attribut écrit dans Entra ID, il persiste. Rebasculer l’ancien serveur n’efface pas la valeur.
Est‑ce que cela écrit quelque chose dans AD on‑premises ?
Non. L’attribut est dans le cloud. Aucun writeback vers AD n’est associé à cette mise à jour.
Comment prouver que c’est bien la seule modification massive ?
En staging, utilisez l’aperçu d’export (Preview/Export) sur un échantillon représentatif et comparez les Pending Exports. Vous pouvez également tracer le volume par type d’opération et valider qu’il s’agit quasi exclusivement d’« Add » sur cet attribut.
Modèle de « Runbook » réutilisable
Objectif
Documenter une fois votre procédure de migration Entra ID Connect afin de la rejouer à l’identique sur d’autres environnements.
Étapes
- Pré‑requis : TLS 1.2, correctifs OS, version SQL supportée, ports sortants, droits AD.
- Installation en staging du nouveau serveur et import de la configuration exportée.
- Audit des règles custom et des filtres d’UO.
- Cycle initial (staging) + contrôles de cohérence.
- Revue du pré‑export (focus sur
onPremisesObjectIdentifier). - Fenêtre de bascule : switch des rôles, surveillance en temps réel, validation métier.
- Stabilisation et rapport de clôture (KPI, volumes, 0 erreurs critiques).
Indicateurs de succès
| Indicateur | Attendu | Méthode de mesure |
|---|---|---|
| Échecs d’export | 0 critique | Operations dans miisclient, Connect Health |
| Type de modifications | >95 % « Add » sur onPremisesObjectIdentifier | Échantillonnage des Pending Exports |
| Temps de rattrapage | < 2 cycles planifiés | Get-ADSyncRunProfile |
| Signal utilisateur | 0 incident d’accès | Centre de service / supervision applicative |
Exemples concrets de vérifications de données
Avant la bascule, choisissez 10–20 comptes témoins : comptes à privilèges, VIP, comptes de service, utilisateurs multi‑domaines. Pour chacun, consignez :
| Élément | Ancien serveur | Nouveau serveur (staging) | Attendu en prod |
|---|---|---|---|
| UPN | Identique | Identique | Identique |
sourceAnchor | Identique | Identique | Identique |
proxyAddresses | Inchangé | Inchangé | Inchangé |
onPremisesObjectIdentifier | Vide | Pending Add | Présent |
| Appartenance groupes | Référence | Conforme | Conforme |
Pièges fréquents et parades
- Changement de filtre d’UO par inadvertance : peut masquer des comptes → vérifiez les Container Inclusions des deux connecteurs.
- Règles custom désactivées après import → revalidez le scope et la précédence, réactivez explicitement si nécessaire.
- Suppression massive accidentelle → gardez le Deletion Threshold actif et confirmé par approbation manuelle.
- Version de schéma AD hétérogène entre forêts → exécutez un import complet par connecteur après mise à jour du schéma.
- PTA/SSO non réinstallé sur le nouveau serveur si vous changiez de rôles → recréez l’agent PTA/SSO si ce serveur devait l’héberger.
Conclusion
Le passage à Microsoft Entra ID Connect v2.3.20.0 via une migration « swing » est une opération faiblement risquée dès lors que les ancrages sont stables, que les règles custom sont correctement réimportées et que vous avez pré‑validé le pré‑export. L’apparition d’écritures sur onPremisesObjectIdentifier est attendue, sans impact fonctionnel et se produit une seule fois lors du premier export. En respectant la checklist ci‑dessus et en gardant un plan de repli simple (staging sur l’ancien serveur), la bascule peut être menée en toute sérénité.